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Preface 


Creating  an  interface  to  a  database  on  a 
microcomputer  is  more  "magic  and  mirrors",  to  quote  a 
standard  saying  in  the  flying  community,  than  anything  else. 
This  is  particularly  true  in  this  case.  Memory  is  at  a 
premium  when  hard  disks  are  not  available.  In  trying  to 
make  a  reasonable  interface  between  someone  without  an 
extensive  programming/database  background  and  a  computer, 
many  short-cuts  and  assumptions  must  be  made.  One  large 
assumption  that  was  made  herein  is  that  a  user  who  needs  to 
use  the  interface  will  not  be  asking  queries  of  a  highly 
complex  nature.  This  allowed  use  of  the  Universal  Relation 
approach  in  attacking  the  database.  Only  queries  that  can 
be  resolved  with  JOINS,  SELECTS,  and  PROJECTS  can  be 
resolved  by  this  interface.  The  specifics  are  inside. 

To  Maj.  Lillie  and  Or.  Hartrum  I  say  thank  you  for 
questioning  the  Universal  Relation.  Your  questions  prodded 
me  to  keep  after  the  project.  To  Dr.  Potoczny  I  say  thanks 
for  providing  a  place  to  think  aloud,  and  for  encouraging  me 
to  keep  after  it.  This  committee  gave  me  reason  to  study 
late  and  long. 

To  my  wife,  Susan,  I  say  thanks  for  putting  up  with 
my  late  nights  -  and  believing  me  when  I  went  in  to  study 


after  hours 
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A  Friendly  Interface  to  a  Relational  Algebra 
Database  System  was  created  on  the  Universal  Relation 
concept.  This  concept  allows  the  user  to  relate  to  the 
total  database  as  a  single  relation.  The  user  inputs  a 
query  using  attributes  of  the  single  relation.  The 
interface  then  creates  the  Universal  Relation  by  way  of 
relational  algebra  JOINS.  Tuples  of  this  relation  are 
SELECTed  according  to  constraints  placed  on  attributes  in 
the  query  (i.e.  CITY  *  NEW  YORK)  ,  and  a  PROJECTion  of 
attributes  desired  is  made  from  the  result.  Limitations  of 
the  interface  are: 


1.  All  relations  in  the  database  must 
be  JOINable  without  data  loss. 

2.  The  query  must  start  with  a  verb. 


Chapter  1 
Introduction 

More  information  is  available  now  than  ever  before,  and 
the  size  and  number  of  databases  are  growing  every  year. 
Virtually  any  topical  area  is  referenced  in  a  database 
somewhere.  However,  only  those  people  who  know  how  to 
access  these  specific  databases  can  get  at  the  information 
inside. 

This  is  a  report  on  a  project  to  make  one  particular 
database  accessible  to  more  people.  This  was  not 
accomplished  by  creating  training  courses  for  potential 
users,  but  by  changing  the  interface  to  the  database,  making 
it  more  friendly.  The  resultant  User-Friendly  Interface 
allows  a  person  with  little  or  no  knowledge  of  the  inner 
workings  of  the  database  to  access  the  information  held 
inside. 

Just  what  is  a  user-friendly  database  interface?  The 
obvious  answer  is  one  friendly  to  the  user.  It  seems  that 
the  friendliness  of  a  database  depends  on  the  knowledge  of 
the  user.  Of  course,  any  interface  at  all  assumes  some 
knowledge  on  the  user's  part;  but  how  much  knowledge,  and  in 
what  areas  is  it  required?  The  more  overlap  the  interface 
has  with  basic  education  requirements,  the  more  friendly  it 
will  be  to  the  greatest  number  of  users.  Naturally,  what  is 
friendly  to  one  user  can  be  unbearable  to  another. 

Many  approaches  to  achieving  a  level  of  friendliness 
a  ;>t  ie  to  a  perceived  user  of  average  intelligence  are 


being  pursued.  The  Artificial  Intelligence  community  is 
studying  ways  to  have  a  computer  verbally  interact  with  the 
user.  Sentence  analysis  of  proper  English  (or  whatever 
language  the  researcher  is  working  with)  is  important  to 
this  study.  A  similar  goal  short  of  overall  verbal 
communication  is  natural  language  interfacing  [27].  A 
natural  language  is  "a  language  whose  syntax  reflects  and 
describes  current  usage,  rather  than  prescribed  usage"  [35]. 

The  natural  language  based  interface  is  promising  for 
large  scale,  future  projects;  but  it  is  too  complex  and  time 
consuming  to  implement  for  purposes  at  hand,  because  it 
requires  recognition  of  parts  of  speech.  Therefore,  a  much 
simpler  approach  to  the  interface  was  taken.  A  simple 
English-like  statement  starting  with  a  verb  makes  up  the 
input  to  the  interface.  This  interface  is  certainly  not 
friendly  to  non-English  speaking  users,  but  the  vast 
majority  of  English  speaking  users  with  an  elementary  level 
education  should  be  able  to  access  the  database  with  this 
interface. 

Assuming  the  user  has  a  minimal  level  of  familiarity 
with  computers,  the  interface: 

1.  Accepts  English-like  input. 

2.  Verifies  input  as  a  valid  request. 

3.  Restates  the  input  in  a  form  consistent 
with  the  database  management  system. 


Background 


In  1979,  Second  Lieutenant  Mark  Roth  designed  a 
relational  database  based  on  relational  algebra  (see  [5,  7, 
27,  33]  for  discussions  of  relational  databases  and 
relational  algebra).  His  purpose  was  to  provide  an 
instructional  tool  for  use  in  database  management.  A  major 
portion  of  the  design  was  implemented.  DCSD  (University  of 
California,  San  Diego)  Pascal  was  used  as  the  programming 
language.  Although  originally  planned  for  an  Altair  8800b 
system,  the  package  now  runs  on  an  LSI-11  at  the  Air  Force 
Institute  of  Technology  (AFIT)  Digital  Engineering  Lab  [29]. 

Roth's  database  is  the  target  database  for  this  user- 
friendly  interface.  The  English-like  input  to  the  interface 
is  transformed  to  relational  algebra  and  is  stored  in  a  file 


Roth  refers  to  as  a  command  file.  This  command  file  can  then 
be  executed  against  the  database  at  the  user's  convenience. 

Captain  Michael  Guidry  designed  a  universal  query 
resloution  system  in  1982.  His  purpose  was  to  implement 
a  software  package  that  could  accept  natural  language 
queries  and  restate  them  in  a  language  easily  translated 
into  a  form  required  by  either  a  network,  hierarchical, 
or  relational  database  (see  [7,  33]  for  discussions  of  these 
database  types).  Guidry  did  not  fully  implement  his  design. 
One  part  of  his  design  that  was  nearly  completed  in 
implementation  was  called  Analyzer.  This  package,  written 
in  UCSD  Pascal,  takes  a  natural  language  input  and  completes 
a  syntax  check  on  the  query  [12].  Analyzer  originally  was 


to  provide  the  interface  created  in  this  project,  however, 
development  of  the  universal  aspect  of  his  query  resolution 
system  kept  Guidry  from  completing  it. 


Objective 

The  objective  of  this  project,  as  stated  earlier,  was 
to  implement  a  User-Friendly  Interface  to  the  Roth 
Relational  Database.  This  was  accomplished  by  supplying  the 
user  with  a  minimal  number  of  rules,  and  showing  him  a 
list  of  the  attributes  available  in  the  database.  The  user 
then  inputs  a  query.  The  interface  translates  this  query  to 
an  intermediate  form  which  reflects  the  syntax  required  by 
the  Roth  system.  This  intermediate  form  is  then  transformed 
to  relational  algebra.  During  transformation,  the  query 
syntax  is  checked.  Finally,  the  query  is  put  on  a  disk  file 
for  future  submission  to  the  Roth  database  for  optimization 
and  resolution. 

The  user  sees  only  the  initial  rules,  the  attributes  of 
the  database,  and  any  error  messages  produced  during 
transformation  of  the  query.  In  this  way,  the  user  is  only 
required  to  know  what  attributes  are  related  to  the 
information  he  desires  to  have. 

Scope 

The  limit  of  this  project  was  to  implement  the 
interface  to  the  Roth  Relational  Database.  Research  in  the 
areas  of  natural  languages  and  relational  databases  was 
used  to  prepare  for  the  task.  Discovery  of  the  Universal 
Relation  concept  of  relational  database  design  (also 


•*  / 


referred  to  as  the  Uniqueness  Assumption)  had  a  major  impact 
on  implementation  of  this  interface  (see  chapter  2) . 

Approach 

Literature  was  researched  in  the  areas  of  natural 
language  and  relational  databases.  Further,  a  capability 
comparison  was  conducted  between  UCSD  Pascal  and  NBS 
(National  Bureau  of  Standards)  Pascal.  The  purpose  of  this 
comparison  was  to  determine  if  a  change  of  programming 
language  would  reasonably  ease  the  size  restrictions 
inherent  to  the  UCSD  Pascal  —  LSI-11  match-up,  without 
requiring  massive  rewrites  of  the  existing  software. 

Next,  a  study  of  the  Roth  database  and  Analyzer  package 
was  conducted  to  give  direction  to  development  of  the 
interface.  This  study  dovetailed  into  the  design  of  modules 
needed  to  complete  the  task. 

Finally,  coding,  testing,  and  integration  of  the 
interface  was  completed. 


Chapter  2 
Concept  of  Design 

Overview 

This  chapter  presents  the  concept  of  a  relational  model 
User-Friendly  Interface.  The  first  consideration  is  what 
information  must  be  provided  to  resolve  a  query  in  a 
relational  database.  Next,  a  discussion  of  how  a  data 
dictionary  could  be  employed  in  query  resolution  is  given. 
This  is  followed  by  a  section  introducing  the  Uniqueness 
Assumption  of  database  design,  and  its  part  in  simplifying 
the  natural  language  to  relational  algebra  transformation. 
The  final  section  is  a  sketch  of  the  interface  created  in 
this  project. 

Relational  Query  Requirements 

Information  is  drawn  out  of  a  database  by  means  of 
queries.  Naturally,  since  computers  do  not  reason,  a 
specific  format  of  information  must  be  provided  to  the 
computer,  directing  it  to  the  data  required.  If  the  query 
does  not  meet  the  format  required,  or  does  not  supply  enough 
information  to  locate  the  data,  the  query  fails.  That  is, 
either  the  computer  returns  an  error  message  indicating  its 
inability  to  find  the  data  from  the  information  given,  or 
incorrect  data  is  returned. 

For  a  relational  database,  the  query  must  indicate: 

1.  What  attributes  are  required  as  the  answer. 

2.  What  attributes  are  required  to  determine 
which  data  are  in  the  answer. 
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3.  What  relations  contain  the  attributes  required 
for  items  one  and  two. 

4.  What  operations  must  be  performed  to  determine 
the  answer. 

5.  Which  relations/attributes  are  related  with 
each  required  operation. 

The  computer's  job  is  to  recognize  relation  and 
attribute  names ,  find  them  in  the  database,  and  apply  the 
specified  operations.  This  is  no  trivial  task,  however. 

Query  preparation  for  this  task  is  more  than  a  database  user 
with  little  or  no  experience  can  handle. 

As  an  example  of  query  recognition  by  the  computer, 
consider  the  part/supplier  database  Date  [7]  uses.  The 
relations  are  named  S,  P,  and  SP.  Attributes  are  as 
follows: 

Relation  S  -  S#,  SNAME,  STATUS,  CITY 

Relation  P  -  P#,  PNAME,  COLOR,  WEIGHT 

Relation  SP  -  S#,  P#,  QTY 

Relation  S  has  information  on  part  suppliers.  S#  is 
the  supplier's  number,  SNAME  is  the  supplier's  name,  STATUS 
is  the  supplier's  status  code,  and  city  is  the  supplier's 
location.  Similarly,  Relation  P  has  information  on  parts  - 
their  number,  name,  color,  and  weight.  Finally,  Relation  SP 
has  shipment  information.  It  tells  which  suppliers  provide 
the  part  in  the  shipment,  which  part  the  shipment  is  made 
of,  and  how  many  total  parts  are  in  the  shipment.  The 
database  is  depicted  in  Table  I. 


Table  I 

PART/ SUPPLIER  DATABASE 


s* 

NAME 

STATUS 

CITY  P 

S* 

P# 

QTY 

si 

SMITH 

20 

LONDON 

SI 

PI 

200 

S2 

JONES 

10 

PARIS 

SI 

PI 

700 

S3 

BLAKE 

30 

PARIS 

S2 

P3 

400 

S4 

CLARK 

20 

LONDON 

S2 

P3 

200 

S5 

ADAMS 

30 

ATHENS 

S2 

P3 

500 

S2 

P3 

600 

P# 

PNAME 

COLOR 

WEIGHT 

S2 

P3 

800 

PI 

NOT 

RED 

12 

S2 

P5 

100 

P2 

BOLT 

GREEN 

17 

S3 

P3 

200 

P3 

SCREW 

BLUE 

17 

S3 

P4 

500 

P4 

SCREW 

RED 

14 

S4 

P5 

300 

P5 

CAM 

BLUE 

12 

S5 

P2 

200 

S5 

P2 

500 

S5 

P5 

500 

S5 

PI 

1000 

S5 

P3 

1200 

S5 

P4 

800 

S5 

P5 

400 

Given  this  database,  a  user  might  want  to  know  the 
supplier's  number  for  all  suppliers  who  supply  part  number 
P2.  It  is  a  simple  task  to  answer  this  query  with  the 
database  laid  out  as  in  Table  1.  Notice,  however,  the 
associations  that  must  be  made  to  answer  the  query: 

1.  The  answer  is  a  list  of  supplier  numbers. 

2.  Supplier  numbers  are  listed  as  S#. 

3.  A  particular  S#  is  in  the  answer  only  if 
the  supplier  belonging  to  that  S#  supplies 
part  P2. 

4.  Part  P2  is  a  specific  value,  listed  under 
the  heading  Pf. 

5.  S#  and  P#  are  only  related  to  each  other  in 


relation  SP 


6.  A  comparison  between  every  Pi  in  relation  SP 
must  be  made  with  the  value  P2. 

7.  The  S#  in  SP  is  recorded  as  part  of  the 
answer  every  time  P#  associated  with  it 
results  in  equality  based  on  the  comparison. 

These  associations  are  very  easy  to  make.  It  is  almost 
difficult  to  believe  all  of  them  are  needed  because  most  are 
automatically  made.  However ,  the  computer  cannot  make  these 
associations,  every  one  must  be  provided. 

Another  example  shows  the  complications  that  can  arise 
in  making  associations: 

QUERY  -  Get  supplier  names  for  suppliers  who  supply  all 
parts . 

ASSOCIATIONS  - 

1.  The  answer  is  a  list  of  supplier  names. 

2.  Supplier's  names  are  listed  as  SNAME. 

3.  SNAME  is  in  the  answer  only  if  that  supplier 
supplies  every  part. 

4.  Parts  are  referenced  by  Pt. 

5.  SNAME  can  be  associated  to  P#  in  relation  SP 
by  way  of  St  (a  complex  association) . 

6.  Every  possible  P#  is  in  relation  P. 

7.  A  comparison  between  every  possible  P#  must  be 
made  with  a  list  of  every  P#  associated  with 
each  S#  in  relation  SP  (a  complex  association) . 

8.  S#  is  saved  if  the  previous  comparison  reveals 
that  this  S#  is  associated  in  relation  SP  with 


every  P#  in  relation  P  (a  complex  association) . 
9.  Every  SNAME  in  relation  S  that  associates  with 
St  in  the  saved  list  is  recorded  as  part  of  the 
answer . 

Associations  five,  seven,  and  eight  are  complex  associations. 
Answering  this  query  by  looking  at  the  database  is  much 
simpler  than  explaining  how  to  answer  it.  Yet,  after  going 
through  the  mental  exercise  of  explaining  it,  one  must  still 
formulate  how  to  explain  the  solution  in  a  language  familiar 
to  the  computer.  The  next  section  deals  with  the  task  of 
explaining  to  the  computer  how  to  make  the  associations  just 
covered. 

Computer  Concepts 

As  previously  mentioned,  a  computer  cannot  make 
associations  by  itself.  Some  sort  of  aid  must  be  provided. 
One  aid  in  use  is  the  data  dictionary.  As  Peters  [25] 
states , 

"The  basic  goal  is  to  create  a  catalog  that 
identifies  each  data  item,  the  data  items  of 
which  it  is  composed  (if  any) ,  any  aliases  by 
which  it  is  known,  and  (when  practical)  the 
values  it  may  take  on". 

A  data  dictionary  for  a  relational  database  should  include 
the  relation  names,  attribute  names,  and  legal  operators. 
Each  entity  in  the  query  is  checked  against  the  data 
dictionary  to  see  if  it  is  a  recognized  name  or  operator. 

If  the  entity  is  found  in  the  dictionary,  appropriate 
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actions  are  taken  to  clearly  indicate  what  the  entity  is  and 
how  it  is  used.  Identified  relations  show  what  attributes 
are  contained  in  them,  identified  attributes  show  which 
relations  they  are  found  in,  and  operators  are  related  to 
their  proper  symbolic  form. 

Consider  the  first  example  query  again: 

"What  is  the  supplier's  number  for  all  suppliers 
who  supply  part  number  P2?" 

Checking  with  the  data  dictionary,  the  resultant  query  is 
built: 

1.  "What  is"  becomes  LIST. 

2.  "supplier's  number”  becomes  Sf. 

3.  "all  suppliers"  becomes  the  condition  ALL 
for  the  operation  LIST. 

4.  "who  supply”  becomes  WHERE. 

5.  "part  number”  becomes  P*. 

6.  "P2"  becomes  a  condition  on  P#. 

The  resultant  query,  LIST  ALL  S#  WHERE  P#  ■  P2,  is  then 
ready  for  resolution.  The  data  dictionary  also  provided  a 
list  of  relations  associated  with  each  attribute  used  in 
this  query.  This  relation  list  is  used  during  query 
resolution. 

It  is  important  to  note  here  the  default  values  of  LIST 
and  the  equal  sign  for  the  condition  on  PI.  These  items  are 
examples  of  capabilities  based  on  semantics  and  syntax  built 
into  an  interface.  How  this  resultant  query  is  produced  in 
this  interface  is  covered  in  chapter  4. 


Uniqueness  Assumption 

The  answer  to  a  query  of  the  form  produced  above  is 
simple  to  produce  under  the  Uniqueness  Assumption  of  the 
Universal  Relation  type  database  [4,  21].  This  type  of 
database  is  formed  so  that  every  internal  relation  can  be 
joined  together  into  a  single  relation  containing  all  of  the 
data  in  the  database.  In  this  one  relation,  each  attribute 
must  have  a  unique  name. 

If  the  database  were  a  single  relation,  most  queries 
would  be  easily  answered  by  a  simple  procedure: 

1.  Find  the  rows  that  meet  the  requirements 
to  be  in  the  answer. 

2.  Take  the  information  from  the  column 
identified  by  the  attribute  requested. 

Using  this  procedure,  the  previous  query  would  be  answered 
by  finding  every  row  in  the  universal  relation  where  P# 
equals  P2,  and  putting  the  S#  from  that  row  in  the  answer. 

These  two  steps  are  effected  by  the  relational  algebra 
SELECT  and  PROJECT  statements.  Rows  are  SELECTed  based  on 
an  attribute's  relationship  to  either  a  specific  value  or 
another  attribute.  Once  the  rows  are  SELECTed,  the 
appropriate  columns  (attributes)  are  PROJECTed  out  into  the 
answer.  The  relational  algebra  for  this  query,  based  on  a 
Universal  Relation  named  TOTAL  is: 

SELECT  ALL  FROM  TOTAL  WHERE  P#  -  P2  GIVING 

INTERMEDIATE. 


PROJECT  S#  FROM  INTERMEDIATE  GIVING  ANSWER 


INTERMEDIATE  is  a  relation  created  by  the  SELECT  statement 
to  hold  the  result  of  that  statement.  ANSWER  is  a  relation 
created  by  the  PROJECT  statement  to  hold  the  final  answer  to 
the  query.  Table  II  depicts  the  Universal  Relation  for  the 
part/ supplier  database,  and  can  be  used  to  verify  the 
procedure . 


Table  II 

PART/ SUPPLIER  UNIVERSAL  RELATION 


s# 

SNAME 

STATUS 

CITY 

P* 

PNAME 

COLOR 

WEIGHT 

QTY 

SI 

SMITH 

20 

LONDON 

PI 

NUT 

RED 

12 

200 

SI 

SMITH 

20 

LONDON 

PI 

NUT 

RED 

12 

700 

S2 

JONES 

10 

PARIS 

P3 

SCREW 

BLUE 

17 

400 

S2 

JONES 

10 

PARIS 

P3 

SCREW 

BLUE 

17 

200 

S2 

JONES 

10 

PARIS 

P3 

SCREW 

BLUE 

17 

500 

S2 

JONES 

10 

PARIS 

P3 

SCREW 

BLUE 

17 

600 

S2 

JONES 

10 

PARIS 

P3 

SCREW 

BLUE 

17 

800 

S2 

JONES 

10 

PARIS 

P5 

CAM 

BLUE 

12 

100 

S3 

BLAKE 

30 

PARIS 

P3 

SCREW 

BLUE 

12 

200 

S3 

BLAKE 

30 

PARIS 

P4 

SCREW 

RED 

14 

500 

S4 

CLARK 

20 

LONDON 

P5 

CAM 

BLUE 

12 

300 

S5 

ADAMS 

30 

ATHENS 

P2 

BOLT 

GREEN 

17 

200 

S5 

ADAMS 

30 

ATHENS 

P2 

BOLT 

GREEN 

17 

500 

S5 

ADAMS 

30 

ATHENS 

P5 

CAM 

BLUE 

12 

500 

S5 

ADAMS 

30 

ATHENS 

PI 

NUT 

RED 

12 

1000 

S5 

ADAMS 

30 

ATHENS 

P3 

SCREW 

BLUE 

12 

1200 

S5 

ADAMS 

30 

ATHENS 

P4 

SCREW 

RED 

14 

800 

S5 

ADAMS 

30 

ATHENS 

P5 

CAM 

BLUE 

12 

400 

The  simplicity  of  this  procedure  makes  use  of  the 
Universal  Relation  very  attractive.  Given  that  the  user- 
friendly  interface  has  to  run  on  a  microcomputer,  any  method 
of  saving  memory  is  worth  looking  into.  Yet,  as  useful 
as  the  method  is  to  the  purposes  at  hand,  there  is  a 
difficulty  with  the  Universal  Relation. 

The  Universal  Relation  method  can  only  be  used  on  a 


database  whose  relations  can  be  joined  into  a  single 
relation  without  loss  of  data.  This  lossless  join  property 
is  not  as  bad  a  problem  as  it  seems,  however.  Ullman  [33] 
states  that  "It  turns  out  that  any  relation  scheme  has  a 
lossless  join  decomposition  into  Boyce-Codd  Normal  Form,  and 
it  has  a  decomposition  into  third  normal  form  that  has  a 
lossless  join  and  is  also  dependency-preserving".  In  other 
words,  when  a  relational  database  scheme  is  designed, 
attention  must  be  paid  to  normalizing  the  internal  relations 
(see  [7,  33]  for  discussion  of  normal  forms).  In  doing  this 
properly,  the  creator  of  the  database  can  go  to  a  third 
normal  form  or  even  Boyce-Codd  normal  form  and  still  be 
compatable  with  the  Universal  Relation  scheme.  Fagin  and 
company  state  further  that  the  lossless  join  property  is 
chief  among  all  desired  properties  in  a  relational  database 
scheme.  By  ensuring  the  scheme  includes  the  lossless  join, 
other  desirable  properites  are  automatically  realized  [10]. 

Beller  [4]  warns  of  the  uniqueness  aspect  of  the 
Uniqueness  Assumption.  He  says  that  the  Universal  Relation 
does  not  reflect  real  world  situations.  His  concern  is 
based  on  a  database  constructed  as  in  Table  III. 

Notice  that  the  attribute  FLOOR  has  a  double 
dependency.  In  relation  MAIN,  it  refers  to  the  floor  the 
DEPARTMENT  office  is  on.  In  relation  WORKER,  FLOOR  refers 
to  the  floor  the  employee  works  on.  Therefore,  any  query 
involving  FLOOR  must  include  which  reference  to  FLOOR  is 
required.  If  the  reference  is  not  included,  workers  could 


be  reported  as  working  on  the  same  floor  as  their  department 
head  office/  when  this  is  not  the  case. 


Table  III 

DEPARTMENT  STORE  DATABASE 


MAIN 

DEPARTMENT 

FLOOR 

DIRECTOR 

Toys 

2 

Jones 

Furniture 

1 

Harris 

Linen 

5 

McKenzie 

WORKER 

EMPLOYEE 

FLOOR 

BOSS 

Tom 

3 

Harris 

Dick 

7 

McKenzie 

Harry 

2 

Jones 

Jones 

2 

Smith 

Harris 

1 

Smith 

McKenzie 

5 

Smith 

Beller  discusses  an  attribute  name  change  method  to 
clear  up  the  ambiguity  presented  by  a  double  use  of  a  single 
attribute.  By  changing  the  attribute  FLOOR  in  relation 
WORKER  to  the  name  PLACE/  the  ambiguity  is  gone.  So  is  the 
capability  for  join.  Therefore,  in  addition  to  renaming 
FLOOR  in  relation  worker,  the  attribute  FLOOR  must  be  added 
to  the  relation  with  data  consistent  to  its  meaning  in 
relation  MAIN. 

Maier  and  Ullman  [21]  take  a  different  approach  to  the 
problem  Beller  presented.  They  work  with  the  database  of 
Table  IV.  In  trying  to  join  these  relations,  ambiguity 
occurs.  This  ambiguity  cannot  be  traced  to  a  specific 
attribute  that  has  a  double  meaning,  however  the  hypergraph 


of  Figure  1  shows  the  candidate  attributes  for  causing  the 
ambiguity.  (A  hypergraph  is  a  graph  in  which  edges  are  a 


}  set  of  nodes.)  A  cycle  is  formed  by  attributes  BANK, 

ACCOUNT ,  CUSTOMER,  and  LOAN.  One  of  these  attributes  is 

1 

'«* 

■  causing  the  ambiguity.  Obviously,  a  BANK  can  be  related  to 

a  CUSTOMER  through  either  a  LOAN  or  an  ACCOUNT.  Using  the 
hypergraph,  and  starting  with  LOAN,  two  paths  to  CUSTOMER 


are  available 


\ 

r, 


.  The  path  by  way  of  BANK  and  ACCOUNT 


Table  IV 

RELATIONS  IN  THE  BANKING  DATABASE 


RELATION 

1 

2 

3 

4 

5 

6 
7 


ATTRIBUTES 
BANK,  ACCOUNT 
ACCOUNT,  BALANCE 
ACCOUNT,  CUSTOMER 
CUSTOMER,  ADDRESS 
LOAN,  BANK 
LOAN,  CUSTOMER 
LOAN,  AMOUNT 


Figure  1.  BANKING  DATABASE  HYPERGRAPH 
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indicates  that  the  customer  has  an  ACCOUNT  at  the  same  BANK 
he  has  a  LOAN,  where  the  direct  path  (LOAN  to  CUSTOMER) 
does  not  infer  anything  about  an  ACCOUNT  in  relation  to. this 
CUSTOMER.  Similarly,  the  paths  from  LOAN  to  BANK  are  at 
odds . 

Rather  than  redesigning  the  database,  Maier  and  Ullman 
propose  using  query  restrictions  by  way  of  maximal  objects. 

A  maximal  object  is  defined  as  a  subset  of  the  Universal 
Relation  within  which  a  query  is  resolved.  Two  maximal 
objects  were  defined  on  the  database  of  Table  4,  the  set  of 
relations  Cl,  2,  3,  4}  and  £4,  5,  6,  7).  Queries  involving 
LOANS  are  routed  to  the  first  maximal  object,  while  queries 
involving  ACCOUNTS  are  answered  from  within  the  second 
maximal  object.  Once  inside  a  maximal  object,  data  outside 
of  that  maximal  object  is  disallowed.  In  this  way, 
ambiguities  previously  present  are  done  away,  while  the 
original  form  of  the  database  is  preserved. 

Maier  and  Ullman  conclude  that  while  the  Universal 
Relation  "may  not  be  perfect  for  everything,  it  does  certain 
things  well  enough  to  be  valued  by  its  users".  At  least 
someone  else  agrees  with  Maier  and  Ullman,  for  King  [18] 
states  that  QUIST  (Query  Improvement  through  Semantic 
Transformation)  is  based  on  the  Universal  Relation  concept. 

Of  course,  QUIST  can  not  handle  every  query  that  can  be  made, 
because  of  its  dependence  on  the  Universal  Relation.  However 
it  does  handle  a  very  important,  large  subset  of  all  queries 
that  are  possible. 


User  Interface 


The  User-Friendly  Interface  created  in  this  project, 
being  based  on  the  Universal  Relation  concept,  requires  that 
the  database  be  well  planned.  As  mentioned  above,  Boyce- 
Codd  or  Third  Normal  form  with  lossless  join  is  required. 

Operation  of  the  interface  is  straight-forward.  Upon 
receiving  the  query,  the  data  dictionary  is  accessed  to 
produce  an  intermediate  query.  All  relations  are  JOINed  to 
produce  the  Universal  Relation,  and  the  intermediate  query 
is  scanned  to  determine  if  a  SELECT  is  required.  If  a 
SELECT  is  required,  it  is  produced,  and  the  intermediate 
query  is  again  scanned  to  determine  the  attributes  required 
in  the  PROJECT. 

The  SELECT  can  be  skipped  if  the  user  fails  fcs  specify  a 
constraint  on  an  attribute  (P#  *  P2).  In  this  event,  the 
answer  will  be  a  PROJECTion  from  the  Universal  Relation. 

After  the  relational  algebra  is  produced,  it  is  shown 
to  the  user.  The  user  is  given  the  opportunity  to  save  the 
relational  algebra  in  a  command  file,  then  is  asked  if  he 
would  like  to  try  another  query.  The  new  query  can  be 
against  the  same  database,  or  disks  can  be  moved  to  run 
against  a  different  database. 


Overview 


Chapter  3 

Constraints  in  Design 


This  chapter  deals  with  various  limitations  and 
situations  encountered  during  the  project ,  and  how  they 
were  dealt  with.  The  first  area  concerned  is  Software 
Capabilities.  The  discussion  reveals  why  NBS  Pascal  (a 
Pascal  compiler  written  for  the  National  Bureau  of  Standards 
at  the  University  of  Montana)  was  chosen  as  the  language  of 
the  interface.  The  second  area  is  hardware.  One  of  the 
requirements  of  this  project  was  that  it  would  run  on  an 
LSI-11  microcomputer.  Why  this  requirement  existed,  and 
considerations  involved  are  dealt  with  in  Hardware 
Limitations.  The  third  section,  Roth  Database  Requirements, 
deals  with  how  the  interface  blends  in  with  the  Roth 
package.  Finally,  Query  Restrictions  tells  what 
restrictions  the  interface  places  on  queries,  and  why  they 
exist. 

Software  Capabilities 

The  Roth  system  was  originally  written  in  UCSD 
(University  of  California,  San  Diego)  Pascal.  Roth  [29] 
cited  five  reasons  for  this  choice: 

1.  Block  structured  design  of  the  language. 

2.  High  degree  of  variable  typing. 

3.  Wealth  of  control  structures. 

4.  Portability. 

5.  Capability  to  handle  large  programs  through 


program  segmentation,  separately  compiled 
procedures,  and  segment  swapping. 

When  the  Roth  system  was  moved  from  the  Intel  8080  to  take 
advantage  of  a  hardware  change  in  the  AFIT  Digital 
Engineering  Lab,  portability  of  UCSD  Pascal  was  tested. 
Second  Lieutenant  Mau  [24]  found  the  task  was  not  as  simple 
as  copy  over  and  run.  When  Mau  finished  the  move  to  the 
LSI-11,  Second  Lieutenant  Rodgers  [28]  tackled  the  problem 
of  finishing  the  implementation  of  the  Roth  system.  Her 
first  obstacle  was  the  block  structure.  Although  UCSD 
Pascal  allowed  segmentation  of  programs  into  independently 
run  segments  [32] ,  seven  segments  were  too  few.  Rodgers 
finally  separated  the  system  into  two  independent  programs 
in  an  effort  to  have  enough  room  to  run  them. 

Unfortunately,  the  Roth  system  still  had  no  ability  to 
actually  receive  data.  Since  the  actual  database  will  take 
some  memory  space,  regardless  of  how  input  and  retrieval  of 
data  is  performed,  the  size  problem  continued.  At  this 
juncture,  the  User-Friendly  Interface  was  introduced. 

Since  the  initial  move  to  the  LSI-11  was  made,  the 
Digital  Engineering  Lab  started  a  project  to  tie  seven  LSI- 
ll's  together  into  a  microcomputer  network.  This  project 
presented  a  logical  solution  to  the  memory  problem  of  the 
Roth  system,  that  is,  move  each  component  to  its  own 
microcomputer,  and  pass  data  between  machines.  However, 
UCSD  Pascal  uses  its  own  operating  system,  and  the  network 
project  was  pursued  in  the  C  language,  based  on  the  RT-11 


operating  system.  Neither  operating  system  (UCSD  and  RT-11) 
can  read  the  disk  directory  of  the  other's  making,  keeping 
the  benefits  of  the  network  from  immediately  being  realized. 
Certainly,  a  program  to  convert  one  directory  to  the  other's 
format  would  work,  but  the  UCSD  segmentation  limitation 
would  still  be  around  to  plague  future  plans  for 
enhancements  to  the  Roth  system.  Clearly,  UCSD  was  a 
limiting  factor  to  further  development  of  the  Roth  system. 

In  1981,  Professor  John  Barr  of  the  University  of 
Montana  headed  a  group  that  released  version  1.6i  of  a 
Pascal  compiler  called  NBS  Pascal  [2].  This  compiler  was 
created  to  run  on  an  LSI-11/23,  and  was  based  in  the  RT-11 
operating  system.  This  Pascal  had  two  major,  practical 
points  in  its  favor  for  replacing  UCSD: 

1.  It  was  already  available  the  Digital 
Engineering  Lab. 

2.  It  was  compatible  with  the  RT-11  operating 
system,  making  files  needed  by  the  interface 
available  for  transfer  on  the  LSI  network. 

In  addition,  being  Pascal,  it  should  make  conversion  of  the 
Roth  system  to  NBS  somewhat  easier  than  a  total  rewrite  into 
another  language.  By  writing  the  User-Friendly  Interface  in 
NBS  Pascal,  the  movement  from  UCSD  would  be  underway. 

While  the  benefits  of  NBS  were  obvious,  they  were  not 
legion,  and  some  drawbacks  existed.  NBS  does  not  support 
strings,  or  string  functions;  and  PACKED,  GOTO,  and  LABEL 
are  recognized  as  reserved  words,  but  no  special  action  is 


taken.  Fortunately,  all  character  arrays  in  NBS  are  stored 
sequentially,  allowing  single  statement  comparisons  and 
assignments  between  arrays  of  the  same  size  (see  chapter  5 
for  more  on  this  area) . 

Hardware  Limitations 

The  Digital  Engineering  Lab  started  acquiring  LSI-11 
microcomputers  in  1980.  Given  the  number  of  users  for  the 
Intel  8080  (where  Roth  implemented  his  database),  the 
decision  to  move  to  one  of  the  five  new  LSI-ll's  was  easy  to 
make  [24].  Since  that  time,  three  more  LSI-ll's  have  been 
acquired.  Of  the  eight  machines,  only  one  is  configured  as 
an  LSI-11/ 23.  This  was  crucial  to  the  NBS  Pascal  decision. 
The  NBS  Pascal  compiler  is  hardware  dependent  to  a  certain 
degree.  One  version  exists  for  the  LSI-11/ 2,  and  another 
exists  for  the  LSI-11/ 23.  This  difference  stems  from  the 
hardware  setup  for  handling  floating  point  numbers.  The 
LSI-11/ 2  has  an  EIS/FIS  (Extended  Instruction  Set/Floating 
Instruction  Set)  combination  on  a  single  chip  [23]. 

Floating  point  calculations  are  handled  by  four 
instructions.  On  the  other  hand,  the  LSI-11/23  has  the 
floating  point  instruction  set  on  a  chip  by  itself.  It 
implements  floating  point  calculations  with  a  set  of  26 
instructions.  The  four  EIS/FIS  floating  point  instructions 
are  not  included  in  the  LSI-11/23  instruction  set.  The 
result  is  that  although  no  floating  point  calculations  are 
done  for  the  database  project,  NBS  programs  compiled  on  one 
machine  will  not  run  on  the  other. 
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Currently,  none  of  the  machines  in  the  LSI  network  is 
an  LSI-11/ 23.  At  least  one  of  the  machines  in  the  network 
could  be  reconfigured,  but  that  point  was  not  critical  to 
the  task  at  hand.  In  the  worst  case,  the  Roth  system  could 
be  relegated  to  a  single  LSI-11/23.  The  memory  problems 
would  still  be  evident,  but  separation  of  the  system  into 
separate  programs  would  be  at  least  as  effective  as  under 
OCSD. 

The  next  worst  case  would  be  to  obtain  a  copy  of  the 
NBS  Pascal  compiler  compatible  with  the  LSI-11/2.  The 
interface  could  then  be  recompiled,  and  the  network  would 
handle  the  memory  restrictions.  Therefore,  the  interface 
project  was  continued  on  the  LSI-11/ 23  in  NBS  Pascal, 
realizing  that  the  resulting  situation  would  compel  a 
decision  to  either  put  LSI-ll/23's  in  the  network  or  get  the 
LSI-11/2  compatible  NBS  compiler  (see  chapter  5,  NBS  Pascal 
on  the  LSI-11/2) . 

Roth  Database  Requirements 

The  Roth  system  implements  a  relational  database  using 
relational  algebra.  It  uses  a  tree-like  structure  to 
perform  its  function  [24,  28,  29].  At  the  second  level  of 
the  Roth  system  tree,  six  functions  are  available: 

1.  SETUP  4.  ATTACH 

2.  EDIT  5.  INVENTORY 

3.  RETRIEVE  6.  QUIT 

Of  these,  only  the  RETRIEVE  function  is  involved  with 
database  queries.  Within  the  RETRIEVE  module  are  five 
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functions  concerned  with  user  queries.  They  are  explained 
as: 

1.  GET  -  Get  a  disk,  file  into  a  specified  memory 
buffer  called  the  workfile. 

2.  SAVE  -  Saves  a  workfile  by  placing  it  on  disk. 

3.  EDIT  -  Allows  creation/ modification  of  the 
workfile. 

4.  EXECUTE  -  Uses  the  workfile  as  a  list  of 
relational  algebra  statements  to  retrieve  data 
from  the  database. 

5.  DISPLAY  -  Shows  the  contents  of  a  relation  on 
the  CRT. 

Obviously,  the  User-Friendly  Interface  belonged  below  the 
RETRIEVE  function,  without  being  able  to  directly  interface 
with  the  Roth  system  due  to  the  UCSD-NBS  incompatibility, 
the  User-Friendly  Interface  had  to  be  self-contained. 

Also,  the  format  of  the  interface  output  had  to  be 
considered.  Two  distinct  possibilities  were  available.  One 
was  to  create,  optimize,  and  store  the  relational  algebra  in 
a  tree-form.  The  other  was  to  produce  a  file  of  relational 
algebra  Roth  calls  a  command  file.  Since  Roth  provides  a 
form  of  query  optimization,  the  second  approach  was  used. 
This  way,  the  interface  makes  use  of  the  Roth  optimizer,  and 
need  not  plan  program  changes  to  accomodate  tree  structures 
stored  in  a  disk  file  for  a  system  that  will  require 
movement  to  another  operating  system,  and  probably  change  in 
the  transfer. 


Query  Restrictions 

Five  rules  are  given  to  the  user  of  the  User-Friendly 
Interface.  Explanation  follows  each  rule. 

1.  A  verb  must  be  the  first  word  in  a  query. 

The  purpose  of  this  rule  is  to  put  the  user  into  a 

specific  line  of  thinking.  By  starting  the  query  with  a 
verb,  the  user  will  typically  follow  with  a  list  of  objects 
he  wants  to  see  in  the  answer.  This  list  of  objects  is 
naturally  followed  by  a  list  of  constraints  on  which 
specific  objects  should  or  should  not  be  in  the  answer. 

That  is,  a  user  wanting  to  know  the  supplier's  name  and  city 
who  supplies  part  P2  might  say  "Show  supplier's  name  and 
city  for  suppliers  of  part  P2".  It  is  this  direction  of 
thinking  that  the  User-Friendly  Interface  depends  on.  The 
verb  itself  is  unimportant.  Actually,  if  no  verb  is  given, 
but  the  line  of  thinking  is  followed,  the  query  will  be 
successful.  This  is  because  the  interface  provides  the 
verb. 

2.  The  rest  of  the  query  must  be  in  sentence 
format  and  use  provided  attribute  names  where 
possible. 

The  purpose  of  this  rule  is  to  further  guide  the  user 
into  the  direction  of  thinking  rule  one  established.  The 
first  part  of  this  rule  is  designed  to  show  the  user  that  he 
can  finish  the  query  in  English  without  an  involved  format 
to  follow.  The  second  part  of  this  rule  requests  the  use  of 
attribute  names.  It  is  crucial  that  attributes  be  used. 


The  interface  does  not  include  an  extensive  dictionary  of 
misspelled  words  or  aliases.  Only  operators,  attributes, 
and  a  few  key  words  pass  the  dictionary  check  to  be  put  in 
the  intermediate  query. 

3.  Specific  attribute  values  must  be  in  quotes. 

Since  the  user's  query  is  taken  to  an  intermediate 

form  without  the  aid  of  a  formal  format,  and  data  is  not 
yet  available,  a  method  of  recognizing  specific  attribute 
values  had  to  be  created.  Otherwise,  the  unrecognized  value 
would  be  deleted  from  the  query.  By  putting  a  beginning 
quote  on  the  value,  the  specific  value  is  signaled.  The 
ending  quote  is  added  as  a  method  of  allowing  the  user  to 
use  a  two  word  specific  value,  as  in  CITY  «  "New  York". 

The  restriction  on  specific  value  length  is  two  words  not  to 
total  more  than  20  characters,  including  intervening  space. 

Certainly,  any  word  following  an  operator  (*,  <,  >,  <>) 
could  be  considered  a  candidate  for  a  specific  value  in  the 
intermediate  query.  However,  in  the  user's  input  of  "Print 
SNAME  for  CITY  equal  to  the  value  New  York",  there  are  three 
intervening  words  (to,  the,  value),  and  no  way  of  knowing 
the  specified  value  is  in  two  parts.  Quotation  marks 
simplified  the  problem. 

4.  You  must  signal  end  of  the  query  by  ending  with 
a  period. 

This  rule  lets  the  user  hit  a  carriage  return  without 
signalling  the  end  of  the  query.  Normally,  a  carriage 
return  signals  end  of  input.  By  waiting  for  a  period, 


the  probability  is  much  higher  that  the  user  finished  his 
input  than  if  a  carriage  return  alone  were  the  signal. 
Carriage  returns  are  almost  a  reflex  action  for  many  who  are 
familiar  with  typewriters  and  keyboards.  This  rule  also 
allows  a  query  to  extend  beyond  a  single  line. 

5.  The  query  may  not  be  more  than  four  lines  long 
(320  characters) . 

Since  NBS  Pascal  does  not  support  strings,  an  array  was 
used  to  hold  the  query.  This  was  deemed  more  feasible  than 
creating  a  linked  list  of  single  characters.  It  is  both 
more  memory  efficient,  and  time  efficient.  The  limit  of 
four  lines  is  given  to  communicate  to  those  unaccostomed  to 
counting  characters.  The  size  of  the  array  (320  characters) 
should  be  sufficient  for  most  queries. 

Rules  one  and  two  presented  the  idea  of  a  direction  of 
thinking  that  would  fit  an  internal  language  format.  This 
internal  language  has  its  roots  in  a  language  used  by 
Cousins  [6].  The  basic  format  of  this  language  is: 

VERB  OBJECT  QUALIFIER 

Cousins  used  the  format  to  build  query  trees  and  determine 
data  access  paths.  Since  the  Roth  system  uses  a  command 
file  to  build  a  query  tree  and  determine  an  optimized  data 
access  path,  the  decision  was  made  to  use  the  same  format 
Cousins  used,  only  for  the  purpose  of  creating  a  command 
file.  This  decision  saved  internal  memory  during  execution 


of  the  interface 


The  VERB-OBJECT-QUALIFIER  format  was  implemented  as 
follows: 

VERB  -  Optional  item.  Default  is  the  word  LIST. 

OBJECT  -  Optional  item.  An  object  is  a  list  of 
one  or  more  attributes. 

QUALIFIER  -  Optional  item.  A  list  of  one  or  more 
qualifiers  joined  by  a  logical  operator 
(AND/  OR) .  The  qualifier  itself  is  an 
attribute-operator-value  grouping. 


Chapter  5  adds  detail  to  this  introduction  of  the  internal 
language,  and  a  Backus -Naur  Form  representation  of  it  is 
presented  in  Appendix  A. 


Overview 


Chapter  4 
Reality  of  Design 


This  chapter  presents  the  structure  of  the  User- 
Friendly  Interface.  Structure  charts  and  algorithm  flows  are 
shown  for  the  most  important  features.  Also  included  is  a 
discussion  of  testing  completed  on  the  interface,  and  a 
sample  of  time  and  disk  space  required  to  process  a  query 
(Table  V) . 

System  Structure 

Figure  2  depicts  the  top  level  of  the  program.  The 
module  MAIN  drives  the  modules  needed  for  communicating  with 
the  user.  All  other  modules  are  invisible  to  the  user 
except  when  an  error  is  discovered  and  reported.  Algorithm 
flow  for  the  MAIN  program  follows: 


Clear  the  CRT. 

UNTIL  the  user  has  disk  space  for  a  file: 

Request  user  identification. 

Ask  the  user  if  disk  space  is  sufficient. 

END. 

WHILE  the  user  wants  to  continue: 

Get  drive  locations  for  data  dictionary  files. 

List  instructions  for  the  user. 

Retrieve  and  show  attributes  from  the  database. 

IF  a  valid  database  is  available: 

Recieve,  translate,  and  edit  the  query. 
Transform  the  query  to  form  relational  algebra 
IF  no  error  occurred: 

Give  user  option  to  save  relational 
algebra. 

END. 

END. 

Ask  user  if  another  query  is  desired. 


The  disk  space  required  on  the  default  drive  is  fairly 
small.  This  question  only  comes  into  play  if  the  user's 
disk  has  no  available  file  larger  than  approximately  10 
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Figure  2.  INTERFACE  TOP  LEVEL 


blocks.  The  RT-11  operating  system  looks  for  contiguous 
space  to  store  files.  Therefore,  even  though  a  disk  may 
have  plenty  of  total  space,  if  no  contiguous  space  is  of 
sufficient  length,  the  file  cannot  be  saved.  During 
testing,  the  interface  created  files  of  up  to  14  blocks,  but 
most  query  command  files  are  5-8  blocks  long.  Because  the 
command  files  created  are  relatively  small,  the  user  is 
advised  to  continue  if  he  does  not  know  how  much  space  is 
available.  Still,  the  safest  method  is  to  do  an  RT-11 
SQUEEZE  of  the  disk,  followed  by  a  DIRECTORY/FULL  to  be  sure 
space  is  available. 


Before  running  the  interface,  in  addition  to  the  space 
requirement,  the  user  should  know  which  disk  has  the 
following  files  on  it: 

SETOP.DAT  -  The  file  produced  by  Roth's  DDL  code 
as  SETUP. DATA.  This  file  name  is  consistent 
with  the  RT-11  operating  system,  which  allows 
filenames  of  six  characters  and  extensions  of 
three  characters.  The  file  contains  domain, 
relation,  and  attribute  definitions  for  the 
database  being  queried. 

STD.DIC  -  A  file  containing  standard  dictionary 
items.  The  file  contains  keywords  and 
operators  most  often  used  in  queries. 

DATBAS.DXC  -  A  file  containing  attribute  aliases 
of  the  database  being  queried.  Probable 
spelling  errors  can  be  put  in  this  file. 
STD.DIC  and  DATBAS.DIC  are  created  by  a  supporting  program 
developed  with  the  interface  called  MAKDIC.  MAKDIC  is 
fully  presented  in  the  "User's  Guide  to  the  User-Friendly 
Interface  to  the  Roth  Relational  Database"  (see  chapter  6, 
Final  Note,  on  where  to  obtain  the  guide) . 

The  user  is  asked,  one  file  at  a  time,  if  that 
particular  file  is  on  the  BOOT  drive.  These  files  contain 
the  only  words  and  operators  that  will  appear  in  the 
intermediate  query  (quoted  specific  values  excepted).  If 
any  one  of  the  files  cannot  be  found,  the  query  translation 
process  could  eventually  fail.  Following  the  questions. 


FORMDICTIONARY  creates  linked  list  dictionaries  from  these 


files . 

The  user’s  query  is  received  by  the  RECVQRY  module. 
When  the  user  completes  input  (signalled  by  a  period), 
PROCESSQRY  is  called  to  take  the  query  to  its  intermediate 
form.  This  translated  intermediate  form  of  the  query  is 
shown  to  the  user,  pending  approval.  If  the  query  is 
approved,  transformation  to  relational  algebra  is 
accomplished.  If  the  query  is  not  approved,  CHANGEQRY  is 
activated  to  allow  the  user  to  designate  where  the  query  is 
incorrect.  When  the  user  finishes  designating  where  the 
error  is,  RECVQRY  is  again  called  to  receive  the  changes. 

PROCESSQRY  contains  the  most  vital  part  of  the 
interface,  the  translation  to  the  intermediate  language. 

The  PROCESSQRY  structure  is  shown  in  Figure  3. 


Figure  3.  THE  PROCESSQRY  MODULE 


The  algorithm  is  a  simple  one: 


WHILE  not  at  the  end  of  input  query: 

Get  the  next  word  from  input  query. 

Translate  the  word  to  the  intermediate  query 


Translate  is  a  culling  operation.  Any  word  (unbroken 
string  of  characters)  not  found  in  one  of  the  three  files  is 
ignored.  If  the  user  followed  the  rules  discussed  in 
chapter  3/  the  resulting  intermediate  query  should  be  of  the 
form: 

LIST  object  [placeholder]  attribute  operator  value 
[logical  attribute  operator  value] 

where : 

LIST  is  the  verb. 

object  is  a  list  of  attributes. 

placeholder,  if  present,  is  one  of  the  words  FOR,  WHEN, 
or  WHERE. 

operator  is  <,  >,  *,  <>,  >=,  or  <*. 

value  is  either  a  specific  quoted  value  or  an 
attribute. 

The  placeholder  provides  a  logical  divider  between  the 
list  of  attributes  for  the  PROJECT,  and  the  first  attribute 
used  as  a  row  SELECTion  rule.  If  the  placeholder  is  not 
there,  the  answer  will  include  a  PROJECTion  of  the  first 
attribute  used  in  the  SELECTion. 

SAVEQRY  gives  the  user  an  opportunity  to  see  the 
relational  algebra  that  was  produced  as  a  result  of  his 
query,  and  decide  if  it  should  be  saved  as  a  command  file. 

If  the  relational  algebra  is  to  be  saved,  the  user  is 
prompted  for  a  filename  to  store  the  relational  algebra  in. 

Translation  of  the  intermediate  query  to  relational 


algebra  is  handled  by  the  ALGEBRA  module,  shown  in  Figure  4 
ALGEBRA'S  flow: 


Create  the  Universal  Relation. 

IF  SELECTion  criteria  exist: 

Produce  relational  algebra  SELECT  statement. 
END. 

Produce  relational  algebra  PROJECT  statement. 
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Figure  4.  THE  ALGEBRA  MODULE 


This  algorithm  totally  depends  upon  the  Uniqueness 
Assumption  discussed  in  chapter  2.  The  Universal  Relation 
is  created  by  JOINing  all  the  relations  in  the  database. 

The  query  is  not  referenced  for  this  step.  Note,  too,  that 
the  algorithm  also  depends  on  the  Roth  optimizer.  JOIN  is 
normally  the  most  costly  operation  in  terms  of  both  time  and 
space,  therefore,  optimization  of  the  query  to  something 
less  than  the  Universal  Relation  that  will  still  answer 
the  query  is  important  (see  chapter  5,  Join  Optimization) . 

The  SELECTion  criteria  can  be  detected  in  many  ways. 

The  most  obvious  indicators  of  the  attribute-operator-value 


construct  are: 


1.  An  attribute  follows  the  placeholder. 

2.  An  attribute  is  followed  by  an  operator. 

3.  A  value  follows  an  operator. 

4.  The  whole  construct  is  found. 

5.  An  operator  is  found. 

The  last  method  was  chosen  as  the  indicator  for  the 
following  reasons: 

1.  The  operator  can  be  detected  in  one  character, 
by  comparison  with  a  set  of  only  three 
characters  (<,  >,  *)  . 

2.  The  operator  can  be  error  checked  in  one  step. 
Currently,  since  Roth  only  allows  <,  >,  and  =; 
the  character  following  the  operator  must  be 
blank. 

The  swift  detection  and  error  check  of  the  operator  takes 
care  of  one-third  of  the  construct  in  minimal  time,  thus 
indicating  presence  of  the  construct  and  partial  processing 
of  it  in  two  steps. 

Testing 

Testing  showed  that  the  interface  responds  as  stated. 
The  test  was  conducted  in  a  top-down  manner.  Each  major 
module  was  tested  independently  before  insertion  to  the 
interface  {minor  modules  were  tested  in  conjunction  with  the 
major  module  they  were  created  to  support).  The  modules 
considered  major  were  MAIN,  GETATTRIBUTES ,  RECVQRY , 
PROCESSQRY ,  SAVEQRY,  TRANSLATE,  ALGEBRA,  JOIN,  SELECT,  and 


PROJECT.  As  each  major  module  was  inserted,  the  resultant 
program  was  subjected  to  an  integration  test.  Finally,  the 
total  program  was  tested,  using  the  test  cases  in  appendix 
B.  The  database  used  for  this  test  was  the  part/ supplier 
database . 

Test  query  5  tries  to  compare  SNAME  and  CITY  -  an 
obvious  error  -  but  no  error  occurs.  This  is  because  the 
interface  checks  attribute  names  for  validity.  SNAME  could 
be  defined  as  the  name  of  the  city  the  supplier's  head 
office  is  in,  while  CITY  could  be  the  city  the  plant  is  in. 
In  that  case,  the  query  would  be  valid. 

Test  query  6  tests  the  capability  to  pass  a  two  word 
specific  value  to  the  Roth  system.  This  two  word  specific 
value  is  not  currently  supported  in  Roth. 

Test  query  12  has  no  error,  yet  has  no  operator.  Since 
no  operator  is  given,  the  interface  does  not  detect  a 
SELECTion  criterion,  therefore,  the  attribute-operator-value 
construct  is  not  violated.  Also,  no  SELECT  statement  is 
created.  As  a  result,  CITY  is  PROJECTed  out  of  the 
Universal  Relation.  Similarly,  query  13  has  no  error 
because  of  the  missing  operator.  However,  the  whole 
Universal  Relation  is  PROJECTed  because  the  placeholder 
WHERE  separates  the  attribute  CITY  from  the  area  reserved 
for  the  list  of  attributes  to  be  PROJECTed. 

Queries  14  and  15  are  similar  in  that  both  seemingly 
have  errors,  but  14  does  not  produce  an  error.  Query  15 
produces  an  error  because  the  word  AND  indicates  that  there 


is  another  attribute-operator-value  construct  following. 
However,  the  operator  (key  to  finding  the  construct)  is 
missing.  This  situation  is  not  discovered  until  after  the 
word  AND  is  reflected  in  the  relational  algebra  being 
produced.  Rather  than  close  the  temporary  file,  read  up  to 
the  word  AND,  and  process  what  is  most  assuredly  a  partial 
query,  an  error  is  generated. 

Query  14,  on  the  other  hand,  has  no  conjunctive  word 
indicating  another  attribute-operator-value  construct  is 
following.  Therefore,  the  relational  algebra  is  produced 
with  assurances  that  some  useful  information  will  be 
retrieved  by  the  query.  This  is  true  due  to  the  nature  of 
the  conjunctives  available  (AND,  OR).  If  the  user  meant  to 
insert  AND,  the  query  would  be  more  restrictive  with  the 
second  attribute-operator-value  constraint.  The  query 
produced  without  the  AND,  and  its  next  constraint,  would 
retrieve  all  desired  information  with  some  unwanted 
information. 

If  the  user  meant  to  insert  an  OR  conjunctive, 
the  information  retrieved  by  the  produced  query  would  be  a 
subset  of  the  information  desired. 

Finally,  Table  V  presents  a  sample  of  disk  space 
and  time  required  to  process  a  query  using  the  part/supplier 


database 


Table  V 

TIME  AND  DISK  SPACE  REQUIRED 


QUERY/ TYPE 

SECS 

BLOCKS 

SS 

18 

5 

DS 

20 

7 

TS 

21 

8 

SP 

16 

3 

DP 

16 

3 

TP 

17 

3 

SP/SS 

19 

6 

DP/SS 

19 

6 

TP/SS 

19 

6 

SP/DS 

21 

8 

DP/DS 

21 

8 

TP/DS 

22 

8 

SP/TS 

22 

9 

DS/TS 

22 

9 

TP/TS 

22 

9 

The  queries  used  for  Table  V  follow: 

SS  (SELECTS  on  a  Single  attribute) 

LIST  FOR  COLOR  IS  "RED". 

DS  (SELECTS  on  two  attributes) 

LIST  FOR  COLOR  IS  "RED"  AND  QTY  IS  "500". 

TS  (SELECTS  on  three  attributes) 

LIST  FOR  COLOR  IS  "RED"  AND  QTY  IS  "500"  AND  S#  >  WEIGHT. 

SP  (PROJECTS  a  Single  attribute) 

LIST  SNAME. 

DP  (PROJECTS  two  attributes) 

LIST  SNAME,  PNAME. 

TP  (PROJECTS  three  attributes) 

LIST  SNAME,  PNAME,  AND  WEIGHT. 

The  other  queries  are  combinations  of  these.  For  example, 

TP/TS  PROJECTS  three  attributes,  and  SELECTS  on  three 


attributes 


Chapter  5 
Recommendations 

NBS  Conversion 

The  Roth  system  should  be  moved  from  UCSD  Pascal.  As 
discussed  in  chapter  3,  DCSD  Pascal  is  restricting  further 
development  of  the  system.  Yet,  OCSD  Pascal  does  provide 
valuable  string  functions.  NBS  Pascal  is  a  viable  choice  to 
move  to,  but  strings  are  not  accommodated.  Conversion  to 
another  language  could  be  worthwhile  if  string  functions  are 
available.  However,  none  of  the  languages  currently 
available  to  the  Digital  Engineering  Lab  except  UCSD  and  C 
support  strings.  Unfortunately,  the  available  C  compiler  is 
not  a  very  good  implementation.  It  is  unreliable,  and 
difficult  to  work  with.  Unless  an  appropriate  language  can  be 
procured,  the  best  option  for  further  development  is  NBS 
Pascal. 

String  Functions 

To  support  a  move  to  NBS  Pascal,  consideration  should 
be  given  to  providing  string  functions  in  the  NBS  compiler. 
Source  code  to  the  compiler  is  contained  in  the  NBS  Pascal 
package.  By  creating  functions  in  the  NBS  compiler 
providing  string  functions  similar  to  the  UCSD  string 
functions,  the  amount  of  change  required  to  make  the  Roth 
system  run  in  the  RT-11  operating  system  would  be  reduced. 

This  particular  project  would  deal  mainly  with  RT-11 
assembly  language  programming.  It  would  be  ideal  for 
someone  interested  in  studying  an  operating  system. 


Memory  Management 

Each  time  the  User-Friendly  Interface  is  run,  three 
linked  lists  are  produced  to  act  as  the  data  dictionary.  At 
the  end  of  processing  a  query,  the  user  has  the  option  to 
cycle  back  to  the  beginning  of  the  program  to  try  another 
query.  If  this  is  done,  three  more  linked  lists  are  created 
since  the  interface  cannot  be  sure  the  user  did  not  change 
disks.  Although  the  first  three  linked  lists  are  not  used, 
they  still  take  up  memory  space.  The  computer  has  no  way  of 
knowing  which  areas  of  memory  once  used  for  the  linked  lists 
are  no  longer  needed  (MBS  does  not  support  the  dispose 
function).  With  the  database  tested,  memory  was  not  filled 
when  multiple  queries  were  run.  That  is  not  to  say  that  it 
might  not  happen  when  using  the  interface,  though. 

Therefore,  a  management  system  for  handling  the  memory  used 
by  the  linked  lists  should  be  installed.  Three  methods  can 
be  used  to  implement  the  management  system: 

1.  Implement  the  dispose  function  in  the  NBS 
compiler. 

2.  Add  modules  to  the  interface  to  track  memory 
allocated  and  released. 

3.  Call  an  external  program  that  chains  back  to 
the  interface  program. 

Although  the  third  method  would  work  if  the  interface  ran 
alone  on  a  machine,  if  it  were  integrated  into  the  Roth 
system  as  planned,  this  would  not  be  advisable. 


Join  Optimization 

Currently,  the  interface  joins  every  relation  in  the 
database,  requiring  that  the  Roth  optimizer  to  be  used  for 
efficient  query  resolution.  Now  that  the  interface  runs  and 
has  proven  its  ability,  it  can  be  changed  to  optimize  the 
relational  algebra.  The  change  entails  allowing  a  JOIN  of 
only  those  relations  actually  required  to  answer  the  query. 
The  SELECT  and  PROJECT  cannot  be  optimized,  since  they  are 
already  in  minimal  form.  To  optimize  the  JOIN,  the 
following  algorithm  should  be  used: 

1.  Make  a  list  of  attributes  required  in  the 
answer  (used  in  PROJECT) . 

2.  Add  attributes  to  the  list  required  in  the 
SELECT  statement. 

3.  Find  the  relation  that  has  as  many  attributes 
from  the  list  in  it  as  possible.  If  more  than 
one  relation  has  the  most  attributes,  use  the 
relation  with  the  least  total  number  of 
attributes. 

4.  Put  the  found  relation  in  a  relation  list. 

5.  If  more  than  one  relation  is  in  the  relation 
list,  JOIN  them,  leaving  only  the  resulting 
relation  in  the  relation  list. 

6.  Delete  attributes  from  the  attribute  list 
that  are  in  the  relation  in  the  relation  list. 

7.  If  any  attributes  are  in  the  attribute  list,  go 
to  step  3. 


These  steps  ensure  the  fewest  number  of  JOINS  by  taking  only 
those  relations  actually  required  in  the  JOIN.  Since  the 
database  scheme  must  have  the  lossless  join  property,  the 
resulting  subset  of  the  Universal  Relation  is  guaranteed  to 
have  the  data  required  in  it. 

NBS  Pascal  on  LSI-11/2 

Professor  Barr  [3]  related  in  a  telephone  conversation 
that  there  is  a  possibility  to  modify  the  NBS  compiler  in 
use  on  the  LSI-11/ 23  for  use  in  a  non-floating  point 
environment  on  the  LSI-11/ 2.  He  stated  that  two  instructions 
in  the  PASLIB.MAC  code  turn  on  the  floating  point 
instruction  set,  SETD  and  SETI.  By  deleting  these  two 
instructions,  the  floating  point  instruction  set  is  not 
activated,  making  the  NBS  compiler  compatible  with  either 
LSI  machine.  Naturally,  the  deletions  would  make  the  use  of 
floating  point  numbers  impossible.  This  change  should  be 
explored. 

Professor  Barr  further  stated  that  an  NBS  compiler  for 
the  LSI-11/2  is  available,  however  it  displays  trouble  with 
floating  point  expressions  due  to  the  way  the  LSI  uses 
registers.  Stack  overflow  is  a  frequent  occurrence,  unless 
the  floating  point  expressions  are  broken  down  to  the 
smallest  possible  pieces. 

Efficiency  Testing 

No  formal  study  of  the  disk  file  space  or  memory  space 
required  was  done  on  the  interface,  nor  was  a  speed  of 
execution  study  run.  Due  to  the  size  of  the  Roth  system,  a 


study  of  how  much  memory  is  required  to  run  the  interface  on 
different  database  sizes  should  be  done.  This  would 
indicate  whether  it  is  feasible  to  incorporate  the  interface 
in  the  same  file  with  the  Roth  USMAIN  [28]  code.  Also, 
formal  study  of  the  size  of  command  file  the  interface 
outputs  will  clarify  how  much  disk  space  the  user  needs  to 
have  before  running  the  interface.  Finally,  a  speed  of 
execution  study  of  the  interface  will  be  useful  in 
determining  how  to  incorporate  the  interface  into  the  Roth 
system. 


Chapter  6 
Conclusion 

Review 

The  goal  of  this  project  was  to  provide  a  User-Friendly 
Interface  to  the  Roth  Relational  Database.  The  result  of 
the  project  is  an  operational  interface,  but  only  users  of 
the  interface  can  really  judge  its  friendliness. 

The  Uniqueness  Assumption  of  the  Universal  Relation 
database  concept  was  introduced.  Exploration  revealed  a 
capability  to  produce  an  interface  of  simple  design.  The 
Universal  Relation  concept  was  adopted,  and  the  interface 
was  designed  and  operating  in  under  two  months. 

Hardware  and  software  constraints  were  examined.  It 
was  discovered  that  NBS  Pascal  is  a  hardware  dependent 
package,  and  has  a  limited  capability.  Still,  the  future  of 
the  Roth  database  system  looks  brighter  on  a  machine  soon 
to  be  in  a  network  situation  than  on  a  single  machine  with 
memory  limitations. 

Constraints  placed  on  the  user  in  using  the  interface 
were  presented.  The  discussion  revealed  that  the  interface 
depends  as  much  on  the  direction  the  user  is  thinking  as  on 
the  format  of  the  query.  Indeed,  the  format  used  is 
reflective  of  the  direction  the  user  should  be  thinking. 

An  introduction  to  the  flow  of  the  interface  was 
given.  Testing  conducted  and  errors  produced  aided  in 
understanding  how  the  interface  works,  and  revealed  the 
thinking  behind  the  purpose  of  the  interface. 


Finally,  recommendations  to  improve  the  system  were 
listed.  Much  more  useful  work  can  be  accomplished  in  the 


Roth  system. 
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Appendix  A 


INTERMEDIATE  LANGUAGE  DEFINITION 
query  ender  (  verb  end er  I  verb  object  ender  I  verb 

object  qualifier  ender  i  verb  object  placeholder 
qualifier  ender 

object  {attribute  <C(3  attribute!! 

qualifier  {attribute  operator  value  {logical  attribute 

operator  value! ! 


ender  . 

placeholder  FOR  I  WHEN  t  WHERE 

value  attribute  I  "database-entry” 

database-entry  : S ■  word  I  word  word 

operator  equal -to  I  greater — than  l  greater-than-or — 

equal -to  i  less-than  I  not— equal  I  less— than— or— 
equal -to 


logical  AND  I  OR 

equal-  to  EQUALS  I  EQ  I  IS  I  EQUAL  I  - 

greater-than  : : ■  GREATERTHAN  I  GT  I  > 
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graatar-than-or-aqual-to  8REATERTHAN0REQUALT0  t  QTEQ  I  >- 

1 •m»-than-or-»qual -to  LESSTHANOREQUALTO  I  LTEQ  I  <- 

1 •••-than  LE88THAN  I  LT  I  < 

not-aqual  NOTEQUAL  I  NE  I  <>  I  !- 


Appendix  B 


Final  Test 

Query:  . 

Test  -for:  Recognize  ender,  automatic  verb  insertion. 
Expected  Results:  JOIN  statements. 

Query:  LIST  SNAME. 

Test  for:  Proper  simple  PROJECT. 

Expected  Results:  JOIN  statements  and  PROJECT  SNAME 

statement. 

Query:  LIST  8NAME,  PNAME,  AND  CITY. 

Test  for:  Proper  complex  PROJECT  statement. 

Expected  Results:  JOIN  statements  and  PROJECT  SNAME, 

PNAME,  CITY  statement. 

Query:  LIST  WHERE  SNAME  «  "TOM". 

Test  for:  Recognize  placeholder,  need  for  SELECT,  quoted 
value,  and  produce  proper  SELECT  statement. 
Expected  Results:  JOIN  statements,  SELECT  WHERE  SNAME  ■ 

TOM  statement. 

Query:  LIST  WHERE  SNAME  -  CITY. 

Test  for:  Recognize  attribute  value  and  produce  proper 
SELECT. 

Expected  Results:  JOIN  statements,  SELECT  WHERE  SNAME  ■ 


CITY  statement 


6.  Query:  LIST  WHERE  CITY  -  "NEW  YORK". 

Tnt  for:  Recognize  two  word  quoted  vtlut. 

Expected  Rasul ta:  JOIN  statements,  SELECT  WHERE  CITY  ■» 

NEW  YORK  statement. 

7.  Quary:  LIST  CITY  -  "LA". 

Tast  for:  No  placeholder. 

Ex pact ad  Rasul ts:  JOIN  statamants,  SELECT  WHERE  CITY  -  LA 

statement,  PROJECT  CITY  ststamant. 

8.  Quary:  LIST  CITY  IS  "LA"  OR  STATUS  >  "40". 

Tast  for:  Racogniza  logical. 

Expactad  Rasul ts:  JOIN  statamants,  SELECT  WHERE  ((CITY  - 

LA)  OR  (STATUS  ✓  40) >  statement, 

PROJECT  CITY  statamant. 

9.  Quary:  LI8T  SNAME,  PNAME,  AND  CITY  FOR  STATUS  >  "60"  AND 

COLOR  18  "RED". 

Tast  for:  Comp lax  quary. 

Expactad  Rasul ts:  JOIN  statamants,  SELECT  WHERE  ((STATUS 

>  60)  AND  (COLOR  -  RED))  statamant, 
PROJECT  SNAME,  PNAME,  CITY  statamant. 

10.  Quary:  LIST  CITY  18  "LA. 

Tast  for:  Impropar  quo tad  valua. 

Expactad  Rasul ts:  Failure  to  process  quary,  statamant 

indicating  ■  followed  by  LA,  which  has 


no  ending  quota 


11.  Query:  LIST  CITY  IS  DARK. 

Test  for:  Illegal  value  DARK. 

Expected  Result*:  Failure  to  process  query,  statement 

indicating  operator  is  followed  by 
illegal  value. 

12.  Query:  LIST  CITY  "DARK". 

Test  for:  Missing  operator,  without  plceholder. 

Expected  Results:  JOIN  statements,  PROJECT  CITY 

statement . 

13.  Query:  LIST  WHERE  CITY  "DARK11. 

Test  far:  No  operator,  with  placeholder. 

Expected  Results:  JOIN  statements. 

14.  Query:  LIST  CITY  18  “DARK"  BNAME  IS  "TOM". 

Test  for:  No  logical. 

Expected  Results:  JOIN  statements,  SELECT  WHERE  CITY  - 

DARK  statement,  PROJECT  CITY 
statement. 

15.  Query:  LIST  CITY  IS  "DARK"  AND  SNAME  "TOM". 

Test  for:  Compound  SELECT  with  no  second  operator. 

Expected  Results:  Failure  to  process  query,  statement 

indicating  the  logical  has  a 
constraint  with  no  operator. 


16.  Query:  LIST  COW  IS  “FAT" . 

Test  for:  Illegal  attribute  COW,  without  placeholder. 
Expected  Results:  Failure  to  process  query,  statement 

indicating  ALL  is  not  an  attribute. 


17.  Query:  LIST  WHERE  COW  IS  "FAT". 

Test  for:  Illegal  attribute  COW,  with  placeholder. 
Expected  Results:  Failure  to  process  query,  statement 

indicating  WHERE  is  not  an  attribute 
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How  MAKDIC  Works 


MAKDIC  creates  th«  fils*  STD. DIC  and  DATBAS.DIC  for 
uu  by  ths  Ussr-Frisndly  Interface.  STD. DIC  contains 
operators  and  ksy  words  used  in  querying  any  database. 
DATBAS.DIC  contains  attribute  aliases  (abbreviations  and 
possible  incorrect  spellings)  for  a  specific  database. 

Thus,  8TD.DIC  need  only  be  created  once,  while  DATBAS.DIC 
needs  to  be  created  for  each  database  created. 

MAKDIC  is  very  easy  to  run.  It  interacts  in  the 
following  manner: 

HOD  OR  CREATE  A  DICTIONARY?  (A  OR  C> 

Response  A  results  in: 

MAKE  SURE  PROPER  FILE  IS  ON  DEFAULT  DRIVE 

Since  the  user  indicated  a  desire  to  add  information  to  an 
existing  dictionary,  he  must  be  sure  the  disk  with  the  file 
he  wants  to  add  to  is  on  the  proper  drive.  Following  this, 
the  user  is  asked: 


ADD  TO  STANDARD  OR  DATABASE  DICTIONARY?  (S  OR  D) 

The  response  causes  either  STD. DIC  (response  S)  or 
DATBA8.DIC  (response  D)  to  be  searched  for  on  the  default 
drive. 

If  the  response  to  the  question  (above): 


ADD  TO  OR  CREATE  A  DICTIONARY?  (A  OR  C) 


had  bNn  C,  the  program  would  have  coma  back  with: 

FILE  WILL  BE  PUT  ON  DEFAULT  DRIVE 

Following  this,  tha  usar  is  askad: 

CREATE  STANDARD  OR  DATABASE  DICTIONARY?  (8  OR  D) 

Tha  file  indicatad  will  ba  craatad  on  tha  da-fault  driva. 

Ragardlass  of  tha  rasponsas  abova,  tha  rast  of  tha 
program  works  tha  sama.  Tha  usar  is  promtad: 

INPUT  WORD  TO  DEFINE 

Tha  program  accapts  any  input,  up  to  20  characters,  than 
prompts  with: 

INPUT  ALIAS  (REPLACEMENT)  FOR  INPUT  WORD 

Again,  a  20  charactar  maximum  langth  input  is  accaptabla. 
This  word  is  tha  "daf ini tion"  of  tha  previous  word. 

Finally,  tha  usar  is  prompted: 

DONE?  <Y  OR  N) 

Only  a  response  of  N  will  causa  the  program  to  loop  back  for 
another  input  word.  Any  other  response  causes  the  file  to 
ba  closed,  and  the  program  to  end. 


Appendix  D 


What  NATQRY  Really  Does 

The  User-Friendly  Interface  is  contained  in  the  files 
NATQRY. <ext>.  NATQRY  is  short  for  Natural  Query.  Running 
NATQRY. SAV  (.8AV  files  are  RT-11  executable  code  files)  is 
accoepl i shed  by  typing  either: 

RUN  NATQRY 
or 

R  NATQRY 

The  coeeand  RUN  is  for  executing  files  on  the  default  drive 
(usually  DYl: ) ,  while  R  (short  for  RUN)  is  for  executing 
files  on  the  boot  drive  (DYO: ) . 

Following  is  a  step-by-step  account  of  what  NATQRY 

does: 

Step  1  -  Request  user's  last  name. 

The  purpose  of  this  step  is  to  get  an  identifier  to  use  in 
database  security.  Since  the  security  features  are  not  yet 
implemented,  no  response  other  than  a  carriage  return  is 
required.  However,  a  name  can  be  entered. 

Step  2  -  Inform  user  that  disk  space  is  required  on  the 
default  drive. 

It  is  assumed  that  the  default  drive  is  DYl:.  The  disk 
space  required  is  relatively  small,  but  if  no  disk  is  in 
drive  DYl:,  or  the  disk  there  is  nearly  full,  the 
opportunity  is  given  to  change  disks.  Typing  the  letter  'N' 
tells  the  system  to  pause  for  a  disk  change  in  the  default 
drive.  Only  typing  the  letter  *Y’  will  allow  the  program  to 
continue,  once  the  disk  is  changed. 


Step  3  -  Request  location  of  files  SETUP.DAT, 
DATBAS.DIC,  and  STD.DIC. 

Each  file  location  is  requested  in  the  following  manner: 

IS  < FILENAME >  ON  THE  BOOT  DRIVE?  (Y  OR  N> 

The  question  for  each  file  must  be  answered  either  by 
the  letter  'N*  or  the  letter  ’ Y' .  Any  other  response  will 
cause  the  question  to  be  reasked. 

A  'Y'  response  indicates  that  a  particular  file  is  on 
drive  DYO:  (the  boot  drive).  An  ’N’  response  indicates  the 
file  is  on  the  disk  in  drive  DYl:. 

SETUP.DAT  is  the  file  created  by  the  Roth  DDL  program 
as  SETUP. DATA.  If  this  file  does  not  exist,  trying  to  run 
NATQRY  is  futile.  The  other  two  files,  STD.DIC  and 
DATBAS.DIC,  are  created  by  the  program  MAKDIC.  At  least 
STD.DIC  must  be  available  to  properly  run  NATQRY.  If 
DATBAS.DIC  is  unavailable,  an  error  message  indicating 
inability  to  open  a  file  will  be  produced,  but  as  long  as 
all  attributes  are  correctly  spelled  (correct  means  the 
spelling  in  the  file  SETUP.DAT),  NATQRY  can  successfully 
run.  The  dictionaries  are  created  when  the  file  locations 
are  all  received. 

Step  4  -  List  the  five  rules  for  making  a  query. 

The  rules  are: 

1.  A  verb  must  be  the  first  word  in  the  query. 

2.  The  rest  of  the  query  must  be  in  sentence  format 
an  use  provided  attribute  names  wherever  possible. 

3.  Specific  attribute  names  must  be  in  quotes,  such 


as  NAME  IS  “JONES 


4.  End  of  query  must  bs  signalled  by  a  period. 

5.  Ths  query  must  not  be  more  than  4  lines  long  (320 
characters,  including  spaces  and  returns) . 

After  reading  the  rules,  hit  the  RETURN  key  to  continue. 

Step  5  -  List  the  attributes  for  the  user. 

The  file  SETUP. DAT  is  accessed  to  show  the  attributes  of 
the  database.  The  attributes  are  listed  in  the  order  they 
are  encountered  in  the  file,  and  put  in  four  columns  across 
the  screen. 

Step  6  ~  Receive  the  user's  query. 

Input  a  query  by  following  the  five  rules. 

Step  7  -  Show  user  the  query. 

When  a  period  is  encountered,  the  system  shows  the  query  as 
it  is  understood.  The  query  is  translated  to  its 
intermediate  form  before  it  is  shown  to  the  user.  If  the 
query  does  not  correctly  reflect  the  intent  of  the  input 
query,  type  *N'.  Any  other  response  is  taken  as  an 
indication  of  a  correct  query. 

An  incorrect  query  indication  sends  the  system  to  Step 
8,  while  a  correct  query  indication  takes  the  system  to  Step 
10. 

Step  8  (Query  was  incorrect)  -  Show  user  instructions 
for  changing  the  query. 

The  instructions  are: 

Input  a  string  of  characters  uniquely  identifying  the  part 
of  the  query  you  want  to  change.  Maximum  length  of  the 
string  is  one  line  (80  characters) . 


THE  QUERY  WILL  BE  OVERLAID  STARTING  AT  THE  FIRST  CHARACTER 
YOU  INPUT. 

Input  string  (  end  with  <CR>): 

Determine  which  character  (in  ths  qusry  ths  system 
showsd)  marks  ths  bsginning  of  ths  incorrsct  information. 
Input  that  charactsr  followed  by  as  many  charactsrs  as 
rsquirsd  from  ths  showsd  qusry  to  idsntify  that  string  as 
its  first  occurrancs.  As  an  example,  supposs  ths  systsm 
said  it  rscsivsd: 

SHOW  BILLY  A  VOLLEYBALL 

If  ths  word  VOLLEYBALL  should  havs  been  FOOTBALL,  enter  a  V 
Since  there  is  only  one  occurrence  of  that  letter,  the 
change  would  start  with  the  space  holding  the  V.  Similarly 
if  BILLY  should  be  BIRD,  the  letter  L  (or  string  LL)  would 
indicate  that  the  change  starts  at  the  first  L  in  BILLY. 

Hitting  the  RETURN  key  after  the  string  moves  the 
program  to  the  next  step. 

8tep  9  (User  is  changing  the  query)  -  Prompt  user  for 
input  to  change  query. 

The  system  displays  this  message: 

Input  changes  (end  with  .): 

The  system  saved  the  query  up  to  the  spot  indicated  in  Step 
S.  The  rest  of  the  query  is  gone.  Any  characters  input 
will  be  appended  to  what  the  system  saved.  In  the  example 
of  changing  VOLLEYBALL  to  FOOTBALL,  the  input  here  would 
have  to  be  FOOTBALL,  even  though  BALL  was  already  in  the 


original  quary  bayond  tha  part  changad.  Aft ar  typing  tha 
period,  tha  system  goas  back  to  Stap  7. 


Stap  10  (Stap  7  quary  was  approvad)  -  Procass  tha  quary 
Tha  systaa  displays  tha  massaga: 

PROCESSING  YOUR  QUERY 

whila  it  transforms  tha  quary  to  ralational  algabra.  If 
arrors  ara  ancountared,  tha  scraan  is  changad  so  that  only 
tha  arror  massaga  is  displayed,  followed  by  tha  massaga: 

Hit  RETURN  to  continue 

Saa  Sac t ion  2  for  arror  massaga  maanings.  If  no  arrors  ara 
encountered,  Step  11  is  performed!  otherwise  Stap  13  is 
performed. 

Stap  11  (No  arrors  in  tha  quary)  -  Show  user  tha 
ralational  algabra  produced. 

Following  the  relational  algabra  statements  is  tha  question: 

Mould  you  like  to  save  it  as  a  command  file?  (Y  or  N) 

If  tha  ralational  algabra  is  unwanted,  type  ’N’.  Any  other 
response  causes  Stap  12  to  be  performed. 

Stap  12  (Sava  tha  ralational  algabra)  -  Request  file¬ 
name. 

Tha  system  shows  this  massaga: 

Input  a  disk  filename  to  save  quary  in. 

If  a  disk  drive  is  not  specified,  the  default 
drive  will  be  used: 

Type  in  a  filename  using  tha  format  <DRIVE  NAME  . EXTENT >. 


DRIVE  is  optional.  If  used,  it  must  bo  oithor  DYO:  or 
DYl:.  DYO:  is  ths  boot  drive,  DYl:  is  the  dofault 
drivo.  If  not  used,  DYl:  is  assumod. 

NAME  is  roquirod.  It  can  bo  from  ono  to  six  char actors 
long.  Tho  first  char actor  must  bo  a  lot tor,  but 
subsoquont  char actors  may  bo  lottors  or  numbors 
(alphanumeric) . 

.EXTENT  is  optional.  If  usod,  tho  period  must  bo  tho 
first  character.  Tho  rest  of  EXTENT  is  from  ono 
to  throe  lottors. 

The  name  of  tho  file  actually  consists  of  NAME.EXTENTl  DRIVE 
is  usod  only  to  detormina  Mhich  disk  to  put  tho  file  an. 

Stop  13  -  Translate  another  query. 

Tho  user  is  asked  if  ho  wants  to  translate  another  query: 

Would  you  like  to  try  anothor  query, 
possibly  on  another  database?  (Y  or  N) 

Only  a  response  of  'N*  will  end  tho  program.  Any  other 
response  will  loop  back  to  Stop  3. 

Disks  (databases)  may  bo  changed  at  this  time.  Do  not 
change  disks  after  giving  the  location  of  the  second  file. 

Also,  only  change  disks  when  the  system  is  awaiting  a  response. 
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What  Error  Massagas  Maan 

BIrll  QEEBAIiyS  SYSIECJ  iBBBSi 

TERROR  OPENING  A  FILE 

—  Running  NATQRY  -  STD.DIC,  SETUP. DAT,  or  DATBA8.DIC 
mas  not  on  tha  driva  indicatad.  Tha  program 
will  conti nua  to  run,  but  translation  to 
ralational  algabra  will  not  ba  succassf ul . 

—  Running  on  an  LSI-11/2  -  Possibly,  tha  driva  nama  in 
NATQRY. PAS  has  not  baan  changad  from  DYO:  to 
DXO: ,  or  from  DYl:  to  DXl:.  Chack  modulas 
GETATTRIBUTES  and  FORMDICTIONARY.  (If  tha 
driva  namas  hava  not  baan  changad  in 
NATQRY. PAS,  than  chack  MAKDIC.PA8  for  tha 
sana  changas. > 

—  Running  any  NB8  Pascal  program  -  A  film  rafarancad 

in  tha  program  by  RESET  or  REWRITE  was  not 

on  tha  disk  driva  spacifiad.  Maka  sura  that 

tha  filanama  is  aithar  in  quotas  < "NATQRY. P A8 •• ) 

or  that  tha  array  passad  to  RESET  or  REWRITE 

has  a  charactar  zaro  (chr(O))  immadiataly 

following  tha  actual  filanama. 

Exampla: 

Program  samplal 
var  afila  :  taxti 

filanama  :  array Cl.. IS 1  of  chart 
bagin 

I  Cstatamants) 

filanamaCll  :■  * N'l 
f ilanamaC23  'A' » 

I  Cspal 1  NATQRY. PAS) 

filanamaC73  | 


f i lenameC83  'P'J 

filename£93  'A* I 

filename! 103:*  'S': 
f  ilenameC113:*  chr  (O)  | 

I  {more  Btatmenti) 

reset (afile,  filename)! 

I  {finishing  statements! 

•nd. 

TERROR  WHILE  DOING  A  BREAK 

—  Running  Pass  ons  of  ths  NB8  Pascal  compiler  -  Ons 

of  ths  files  being  created  Mas  not  allocated 
enough  disk  space. 

Example: 

.R  PA881 

*-  NATQRY.PAS  INTC303  DATE  103  LSTC2203 

TERROR  WHILE  DOING  A  BREAK 
The  error  says  that  either  INT,  DAT,  or  LST 
requires  more  space  than  allocated  (30,  10, 
220  BLOCKS  -  See  NBS  Compiler  Notes)  or  the 
disk  does  not  have  enough  contiguous  space  to 
accommodate  one  or  more  of  the  requested  file 


WIQBX  BESSdfiES 

UNABLE  TO  PROCESS  YOUR  QUERY  DUE  TO  ERROR 

-  Standard  trror  message  haadar. 

<op>  is  an  ill agal  oparator. 

Tha  Roth  systaa  only  allows  <t  >,  or  ■ 

-  <op>  is  ona  of  tha  following:  <>,  <«,  >■ 

Tha  intarfaca  undarstands  not  aqual ,  lass 

than  or  aqual  to,  and  graatar  than  or  aqual 

to |  but  tha  Roth  systaa  doas  not. 

Cop >  is  followad  by  <word> 
which  has  no  anding  quota 

-  <op>  is:  C,  >,  or  ■ 

<word>  is  a  word  froa  tha  input  quary  that 
has  a  starting  quota.  Sinca  no  anding  quota 
was  given,  tha  intarfaca  cannot  tall  if  this 
ona  word  Is  tha  whola  spacifiad  valua,  or  if 
tha  next  word  should  ba  part  of  tha  spacifiad 
valua.  That  is,  if  <word>  was  "NEW,  tha 
intarfaca  cannot  tall  if  that  is  tha  first 
part  of  "NEW  YORK"  or  just  "NEW". 

Oparator  <op>  is  followad  by  a 

valua  that  is  naithar  an  attribute,  nor  quoted 

-  <op>  is:  C,  >,  or  ■ 

An  unclear  rule  on  how  to  select  which 
information  to  retrieve  was  givan. 

Example: 

LIST  PNAME  FOR  CITY  IS  DENVER. 

DENVER  is  not  quoted,  indicating  it  is 
not  a  value  found  in  tha  database  under  tha 


nams  CITY.  Howavsr,  DENVER  is  also  not  an 
attribute  in  ths  database.  Ths  intarfaca 
doss  not  know  whars  to  find  what  DENVER  isl 
and  without  knowing,  ths  correct  PNAME  cannot 
bs  found. 

Opsrator  <op>  is  not  prscssdod  by  an  attributs 

-  <op>  is:  <,  >,  or  ■ 

Similar  to  ths  error  abovs,  sxcspt  that  ths 

word  in  front  of  Cop >  is  not  an  attributs. 

Logical  <log>  has  invalid  constraint  following  it. 

Ths  constraint  has  no  opsrator. 

-  <log>  is  AND  or  OR 

A  qusry  indicating  mors  than  ons  ruls  on 
which  data  to  sal act  was  input.  Howsvsr, 
a  ruls  following  <log>  had  no  opsrator  (C,  >, 
or  ■)  in  it. 

Exampls: 

LIST  PNAME  FOR  CITY  IS  "DENVER1*  AND  8NAME  "82 
Only  PNAMEs  associatsd  with  DENVER  and  82  ars 
dasirsd,  but  it  is  unclsar  whsthsr  SNAME  is 
mors,  lass,  or  squal  to  82.  Ths  constraint 
CITY  IS  "DENVER"  is  lagal,  ths  constraint 


SNAME  "82"  is  not 
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NB8  Compiler  Notes 


PA86UI.DOC  is  the  disk  file  sent  with  the  NB8  Pascal 
package  that  explains  what  NBS  does  and  doesn't  do.  The  few 
notes  here  are  covered  in  PASGUI.DOC,  but  are  not  as  easy  to 
find  in  that  document  -  nor  as  easy  to  understand. 


Uhst  SES  euui  Qfici  UQI  SuMQCt 


Chaining 


DISPOSE 


SOTO 


LABEL 


♦PACKED  ARRAY  8TRIN8S 


♦♦Passing  Procedure/Function 

Parameters 


String  Functions 


The  Roth  Database  system  uses  string  functions 
(Position,  Concatenate,  etc.)  and  some  GOTOs.  Changes  must 
be  made  to  the  Roth  code  to  transfer  the  system  to  NBS 
Pascal . 

*  All  character  arrays  are  PACKED.  Therefore,  single 
statement  compares  and  assignments  of  the  same  TYPE  arrays 
are  supported: 


program  compare) 
var 

dog,  cat  :  packed  arrayC1..33  of  char) 
begin 

dog  'DOS') 

cat  'CAT') 

if  (dog  “  cat) 

then  writelnCDog  is  weird') 
else  writeln('Dog  is  normal') 

end. 


♦♦  Paragraph  3.9  or  PASGUI.DOC  references  passing 
procedural  and  functional  parameters.  The  statements  are 


not  obvious  in  their  moaning.  However,  tha  -following 
program  amgmmnt  dmpicts  a  situation  that  does  not  run 
properly,  because  it  violates  this  paragraph: 


program  linked_list| 
type 

list  ■  record 

name  :  array Cl.. 203  of  charl 
ptr  :  "*1  ist 

end  | 
var 

base,  temp  :  "*list| 

word  :  array Cl.. 203  of  charl 

procedure  walk(var  POINTER  :  "*list)f 
begin 

if  (POINTER"*. name  <>  word)  <  Chain  down  the  list  } 
then  wal k (POINTERS. ptr  > 

end  | 

begin 

I 


I 

end. 


The  program  will  compile  without  error,  but  the  procedure 
will  not  properly  chain  down  the  list.  This  is  because  the 
variable  POINTER  was  declared  in  the  procedure  header, 
making  it  a  procedural  parameter.  Subsequent  passing  of 
POINTER  to  any  other  procedure  (even  WALD)  is  illegal.  A 
test  of  this  recursive  call  setup  to  chain  down  a  linked 
list  resulted  in  the  procedure  calling  itself  in  an  infinite 
loop.  By  looking  at  POINTER  addresses,  it  was  determined 
that  WALK  properly  chained  two  links  down  the  list,  then 
reset  itself  to  the  beginning  of  the  list. 
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I itait  MBS  fiddid  is  Eaicil 

BREAK  is  a  function  addsd  to  Pascal  for  output  to  a 
fils.  Writs  statsssnts  to  any  fils  ars  buffsrsd  and  hsld 
until  ths  buff sr  is  full,  or  a  BREAK  to  ths  fils  is  issusd. 
This  allows  ths  program  to  run  slightly  fastsr  by  not 
intsrrupting  flow  for  I/O  until  rsquirsd.  In  a  PROMPT- 
RESPONSE  situation,  if  BREAK (output )  is  not  issusd,  ths  ussr 
will  bs  rsquirsd  to  rsspond  to  a  prompt  hs  did  not  rscsivs. 
An  sxampls  follows: 

program  prompt I 
var 

nams  :  array Cl.. 153  of  char I 
bogin 

writsln < 'ENTER  NAME')* 
rsadln (nams) 
snd. 

Whan  this  program  is  run,  nothing  sssms  to  happsn.  Aftsr 
ths  ussr  sntsrs  sons  char act srs  and  a  carriags  rsturn,  ths 
statsmsnt  ENTER  NAME  appsarsf  and  ths  program  snds.  By 
inssrting  "brsak (output ) I "  bsfors  ths  rsadln,  ENTER  NAME 
will  appsar  bsfors  ths  ussr  can  sntsr  his  nams. 

BuoQlQfl  tbi  BBS  CfifflBi.lt!: 

Finally,  a  fsw  notss  on  running  ths  compilsr.  Ths 
filss  that  maks  up  ths  compilsr  havs  bssn  rsnamsd  in  ths 
Digital  Enginssring  Lab  (DEL): 

eassui^BQC  eEiiatsL 

PA8S1F.8AV  P1.8AV 

PASS2F.SAV  P2.8AV 

NPA8L . OBJ  NB8LIB. OBJ 

CPA8L . OBJ  CPASL . OBJ 


These  -filas  are  compatibla  with  tha  LSI-11/23  (Programs 
craatad  with  thasa  -filas  will  only  run  on  LSI-1 1/23 
machinas).  Different  names  should  ba  given  tha  filas  for 
tha  LSI-11/2. 

File  size  and  disk  space  are  major  concerns  when 
running  tha  NBS  compiler.  Merely  entering  a  command  such  as 


.R  PI 

*-  PROS. PAS  I NT  DAT  LST 

is  only  sufficient  for  small  files.  Tha  compiler  needs  to 
know  how  large  INT,  DAT,  and  LST  are  going  to  be.  For  a 
fully  commented  program  with  module  headers,  PROS. PAS  can 
overfill  the  default  sizes  given  to  INT,  DAT,  and  LST  when 
it  is  only  26  to  30  blocks  long.  (INT  and  DAT  are 
intermediate  files  used  by  pass  two  to  create  the  program’s 
object  file.  PAS8UI.DOC  suggests  using  the  names  INT,  DAT, 
and  LST  rather  than  PROS. INT,  PR08.DAT,  and  PROS. LST.  LST 
is  an  error  listing  file.  All  three  files  must  be  specified 
for  pass  one  to  run,  and  the  dash  must  both  be  flush  against 
the  asterisk  and  have  a  space  between  it  and  INT.  Pass  one 
supplies  the  asterisk  as  a  prompt.)  During  pass  one,  if  one 
of  the  files  should  be  filled,  the  system  error  7ERR0R  WHILE 
D0IN8  A  BREAK  is  produced.  This  error  is  sent  to  the  CRT 
for  almost  every  line  of  code  encountered  after  the  file  is 
filled,  giving  an  indication  of  how  near  the  end  pass  one 
got. 


To  remedy  the  full  file  error,  square  brackets  are  used 


s 


to  give  the  system  maximum  -film  sizms: 


.R  PI 

*-  PROG. PAS  I NT C 20 3  DATE  103  L8TC1003 


This  command  lmts  INT  take  up  to  20  contiguous  blocks  be-form 
it  -fills.  Naturally,  DAT  gets  10  blocks,  and  L8T  gets 
100.  Guessing  what  size  to  allow  is  a  trick.  For 
NATQRY.PAS  (the  User-Friendly  Interface  file),  the  following 
file  sizes  were  used: 


File 

Size 

NATQRY.PAS 

142 

INT 

29 

DAT 

6 

L8T 

210 

As  NATQRY  grew  during  development,  this  rule  of  thumb  was 
developed  "Allow  INT  20X  of  the  size  the  source  file  has, 
let  L8T  have  150X  of  source,  and  give  DAT  20  blocks”.  DAT 
fluctuated,  but  never  got  as  large  as  15  blocks,  however 
other  compiled  files  have  reached  18  blocks  for  DAT.  All  of 
these  files,  naturally,  require  contiguous  disk  space. 
Frequent  use  of  the  SQUEEZE  command  is  highly  recommended. 

The  second  pass  of  the  NBS  compiler  never  required 
specifying  the  file  size,  however,  the  option  is  available: 

.R  P2 

*-  INT  DAT  PROG. OBJ C623 


*  v.s's'.v 


"v  -/ a-V.V.vVa'.sV.-.-  .  . 


Again,  like  pass  one,  the  asterisk  is  a  supplied  prompt,  and 
the  dash  must  be  placed  exactly  as  shown  (unless  options  are 
used,  in  which  case  option  letters  would  immediately  -follow 
the  dash) . 

The  LINK  is  the  standard  RT-11  LINK.  However,  if  the 
pascal  program  being  created  sends  very  many  messages  to  the 
CRT,  the  LINK  command  will  need  to  use  the  BOTTOM  option. 
This  is  because  of  the  way  RT-il  uses  registers  in 
Input/Output.  The  stack  overflows  quite  rapidly.  The 
default  stack  has  its  top  at  address  0400,  and  bottom  at 
1000.  It  can  be  lengthened  by  moving  the  bottom  of  the 
stack,  as  follows: 


.LINK/B0TT0M: 004000  PROS, NBSLIB 

This  command  moves  the  bottom  of  the  stack  to  address  4000, 


increasing  the  stack  size  by  a  factor  of  about  4.  This 
happens  to  be  the  size  stack  NATQRY  uses. 


FINDQUOTED  I  DOW HERE 

I 

FINDOPERATOR 


SETERROR  i  NEWREL 

I 

FINDLOGICAL 


DOWHERE 


I 

F I NDATTR I BUTE 


PUTFILE 


FI NDATTR I BUTE 

„  _  I 


I 


I 


» 


QETWORD  SETERROR  CHECKATTR I BUTE 


FINDOPERATOR 


SETERROR 


FINDQUOTED 


SETERROR 


QETWORD 


CHECKATTR I BUTE 


FINDLOGICAL 

l 

QETWORD 


GETDRIVE8 


REQUEST ID 


CLEARLINE8 


CLEARLINES 


FORMDICTIONARY 

I 

CLEARLINES 


LISTIN8T 

I 

CLEARLINES 
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h**«***********#***»*«*******#*********************«******« 

DATE:  S  Sep  S3  * 

FILE:  NATQRY.PAS  * 

FUNCTION:  Interfaces  with  user  to  allow  him  to  query  the* 
Roth  Relational  Database  without  knowing  * 

Relational  Algebra.  The  actions  taken  are  * 

based  on  the  Universal  Relation  idea.  See  * 

Thesis  written  by  Capt  Dale  VanKirk  in  1983  * 

for  further  explanation.  * 

FILES  READ:  SETUP.DAT ,  STD.DIC,  DATBAS.DIC  * 

SETUP.DAT  -  The  file  created  by  the  Roth  DDL* 
package.  It  contains  domain,  * 

relation,  and  attribute  * 

definitions.  * 

* 

STD.DIC  -  The  STANDARD  DICTIONARY  file  * 

created  by  a  separate  program  * 

named  MAKDIC.  MAKDIC  is  written  in* 
Pascal  (NBS),  and  is  to  be  used  by* 
the  DATABASE  ADMINISTRATOR  to  * 

create  the  dictionaries  required  * 
to  run  this  program.  * 

* 

DATBAS.DIC  -  Also  made  by  MAKDIC  —  This  * 

dictionary  is  specific  to  the  • 

database  in  use.  It  contains  * 

aliases  for  attributes.  * 

* 

FILES  WRITTEN:  QRYTMP.TMP,  and  a  User  specified  file.  * 

* 

THE  USER  SPECIFIED  FILE  EQUATES  TO  A  ROTH  COMMAND  FILE  * 

* 


QRYTMP.TMP  -  A  temporary  file  written  to  * 
hold  all  of  the  relational  * 
algebra  commands  made  to  * 
fulfill  the  Natural  language* 
query.  It  is  created  on  the* 
default  disk,  and  rewritten  * 
(erased,  however  name  is  * 
left  on  disk  directory)  when* 
no  longer  needed.  * 

User  specified  -  File  named  by  the  user  * 
to  hold  the  relational  * 

algebra  in.  This  allows  the* 
user  to  build  many  queries  * 
at  running  of  NATQRY.  Disks  * 
can  be  changed  allowing  * 
different  databases  to  be  * 
queryied. 

AUTHOR:  VanKirk 
********************** 


* 

> 


program  natural query) 


const 

trash  -  ’•') 

spacs  ■  '  *1 

•ndsr  ■  ' . ' | 

typs 

short  “  packmd  array Cl.. 203  of  char) 


listrsl  ■  record 

r el name  :  short) 
used  :  char ) 
at r pointer  :  '"‘list) 
rel pointer  :  '“listrel 
end  | 

listatr  *  record 

atrname  :  short) 
pointeratr  :  ^listatr) 
pointer rel  :  "'list 
end) 


list 


record 

identifier 
pointer  :  ' 
end) 


:  short ) 
list 


var 

at r base,  atrptr  :  ^listatr) 
rel base,  relptr  :  ^listrel) 
at  r  temp,  rel  temp  :  ''list) 


<  List  keyed  on  attributes  > 

<  List  keyed  on  relations  > 

(  at r temp  points  to 
attributes  in  list  keyed  on 
relations,  rel temp  points  to 
relations  in  list  keyed  on 
attributes.  > 


query  :  packed  arrayCl 

j  :  integer) 
length  :  integer) 
stopprocess  :  boolean) 
setdrive  :  char) 

stddrive  :  char) 
datdrive  :  char) 
lines  :  integer) 

continue  :  boolean) 


ch  :  char ) 


.3203  of  char) 

{  The  Query  > 

{  Counter  for  stepping  thru  query  > 

{  Actual  length  of  query  > 

C  Stop  program  if  no  database  > 

<  Answer  to  question  "Is  SETUP.DAT 
on  BOOT  DRIVE?"  > 

<  Is  STD. DIC  on  BOOT  DRIVE?  > 

C  Is  DATBA8.DIC  on  BOOT  DRIVE?  > 

C  Number  of  clean  lines  to  append 
on  screen  > 

<  Lets  user  loop  through  program 
to  create  another  command  file 
using  same  or  different  database  > 

<  To  receive  user  response  in  MAIN  > 


datbase,  stdbase,  dattemp,  stdtemp  :  "'list) 

{  Standard  dictionary  (stdbase) 


and  database  dictionary  (datbase)  > 

word  :  short | 

i  Holds  word  whils  chocking  dictionaries  > 
end query  :  boolsanf 

i  Indicates  end  o-f  original  query  reached  > 
call translate  :  integer I 

{  Counter — type  flag  indicating  need  to  check 
for  first  verb  > 

newquery  :  packed  array! 1. .3203  of  char! 

<  Intermediate  query  between  input  and 
Relational  Algebra  > 

nq  :  integer!  <  Counter  to  step  thru  newquery  > 

{**«**#****************#*****************> 
procedure  changeqry!  forward! 
{******«#********************************} 


{»**1HHHHHHHHHH»***«*****##**«************» 

*  DATE:  22  Aug  83  * 

*  MODULE:  Cl ear lines  * 

*  FUNCTION:  Appends  specified  number  of  * 

*  blank  lines  to  screen.  * 

*  INPUTS:  lines  * 

*  OUTPUTS:  none.  * 

*  LOCAL  VARIBLES:  i  * 

*  GLOBALS  USED:  none.  * 

*  MODULES  CALLED:  none.  * 

*  CALLED  BY:  main,  getdrives,  requestid,* 

*  listinst,  formdictionary,  * 

*  recvqry  * 

*  AUTHOR:  VanKirk  * 

**#**********«»•**«***«******************} 


procedure  clearlines) 


i  :  i nteger | 
begin 

for  i  :■  1  to  lines  do  mritelnj 
break (output) 
end  | 
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{****#*#*********#****#*****#*####******** 

*  DATE:  22  Aug  83  * 

*  MODULE:  Betdrives  * 

*  FUNCTION:  Retrieves  information  on  * 

*  which  drive  hes  files  needed* 

*  INPUTS:  User  supplied  * 

*  OUTPUTS:  setdrive,  stddrive,  detdrive  * 

*  LOCAL  VARIBLES:  getinfo  * 

*  6L0BALS  USED:  setdrive,  stddrive,  dat-* 

*  drive,  lines  * 

«  MODULES  CALLED:  clesrlines  * 

*  CALLED  BY:  mein  * 

*  AUTHOR:  VanKirk  « 

*****************************************> 

procedure  getdrives! 

var 

getinfo  :  boolean! 
begin 

getinfo  : ■  true!  {  Find  out  drive  relation/attribute  > 

while  getinfo  do  C  definitions  are  on  > 
begin 

writeln ( *  Is  SETUP. DAT  on  the  BOOT  DRIVE?  (Y  or  N) ' ) ! 

break (output)  I 

lines  12) 

cl ear lines! 

readln (setdrive) | 

if  ((setdrive  »  ’Y’)  or  (setdrive  ■  'N')) 
then  getinfo  :»  false 

end! 

clearlines! 

getinfo  : ■  true!  <  Find  out  drive  standard  dictionary  > 
while  getinfo  do  <  definitions  are  on  > 
begin 

writeln (’Is  STD.DIC  on  the  BOOT  DRIVE?  (Y  or  N) ’ ) I 
break (output) ! 
clearlines! 
readln (stddrive) ! 

if  ((stddrive  ■  'Y')  or  (stddrive  «  ’N')) 
then  getinfo  : “  false 

end! 

clearlines! 


getinfo  : ■  true!  <  Find  out  drive  data  base  dictionary  > 
while  getinfo  do  <  definitions  are  on  > 
begin 

writeln ('Is  DATBAS.DIC  on  the  BOOT  DRIVE?  (Y  or  N) ’ ) I 
break (output) ! 
clearlines! 
readln (datdri ve) I 


c ***************************************** 


*  date:  11  Aug  83  * 

*  MODULE:  Set at t r i but am  * 

*  FUNCTION:  Accesses  file  SETUP. DAT  and  * 

*  creates  structures  to  use  * 

*  as  database  dictionary.  One  * 

*  structure  (  relbase  root  >  * 

*  keyed  on  relations,  the  * 

*  other  <  atrbase  root  )  is  * 

*  keyed  on  attributes.  Also  * 

*  outputs  a  list  of  attributes* 

*  to  help  user  make  query.  * 

*  INPUTS:  none.  * 

*  OUTPUTS:  2  record  structures  with  * 

*  relbase  and  atrbase  as  roots  * 

*  LOCAL  VARIBLES:  ch,  i ,  k,  count,  « 

*  constraint,  atfile,  * 

*  relationend,  savechar  * 

*  6L0BALS  USED:  stopprocess  * 

*  MODULES  CALLED:  none.  * 

*  FILE  READ:  SETUP.DAT  * 

*  CALLED  BY:  main  * 

*  AUTHOR:  VanKirk  * 

a****************************************! 


procedure  getattributesl 


atfile  :  text} 

count,  i,  k  :  integer! 

relationend,  constraint  :  boolean! 

ch,  savechar  :  char! 

holder  :  short! 

begin 

new (atrbase) ! 
new (relbase) ! 
atrptr  :■  atrbase! 
relptr  :■  relbase! 
atrptr'*.  pointer  atr  :■  nil! 
atrptr^.pointerrel  :■  nil! 
relptr^.atrpointer  :■  nil! 
relptr^.relpointer  :■  nil! 


if  (setdrive  -  *Y') 
then  reset (atfile, 
else  reset (atfile. 


"DYO: SETUP. DAT") 
"DYi: SETUP. DAT")! 


i  :-  1! 

read (atfile,  ch)! 
while  (ord (ch)  <>  13)  do  <  Read  first 

begin 

holder Cil  : ■  ch! 

if  not  eof (atfile)  then  read (atfile,  ch)! 
i  i  ♦  1 


$ 


while  (i  <  21)  do 
begin 

hoi dor Ci 3  :»  ’ 
i  :«  i  1 
and) 


savechar  : < 


if  (hoi der  <>  *NODOMAINSDEFINED  ') 

<  Th ere  is  a  database,  skip  dosain  definitions  > 

then 

while  (not  eof(atfile)  and  (ch  <>  '#’))  do 
begin 

readln (atf i le,  ch)| 
if  (not  eof(atfile)  and  (ch  -  **')) 
then  read ( atf ile,  savechar)! 
if  (savechar  -  '*') 
then 
begin 

stopprocess  :*  truel 

(  Domains  defined,  but  no  relations! !  > 
writelnC SORRY,  NO  RELATIONS  DEFINED*)! 
while  not  eof(atfile)  do  read (atf ile,  ch) 
end 


begin 

writelnC SORRY,  NO  DATABASE  DEFINED*)! 
stopprocess  :■  true! 

while  not  eof(atfile)  do  read (atf ile,  ch) 
end| 


if  ((not  eof(atfile))  and  (ch  ■*#*)  and  (savechar  <>  ***' 
then  ch  : ■  savechar! 

(  Savechar  holding  first  letter  of  relation  name  > 


if  not  eof(atfile) 
then 

begin  <  Save  relation  name  > 

•  m  1 1 

while  (ord (ch)  <>  13)  do  i  Check  for  end  of  line  > 
begin 

relptr^.relnameCkl  :«  chi 
read (atf ile,  ch)| 
k  !■  k  +  1 
end! 


while  (k  <  21)  do 
begin 

relptr^.relnameCkl  !■•  *  *| 
k  :■  k  ♦  l 
end! 


{  Bet  rid  of  line  feed  > 


read  (et-f i  le,  ch) 
end  I 

if  not  eof<atfile)  then  read(atfile,  ch)j 

f  Read  first  letter  of  attribute  > 

new(relptr^.atrpointer) I 

at r temp  : ■  rel ptr^.atr pointer) 

while  not  eof(atfile)  do 

begin  i  Save  attribute  name  in  list  keyed  on  relations  > 
k  If 

while  (ord(ch)  <>  13)  do  <  Check  for  end  of  line  > 

begin 

atrtemp'".  identifier  Ck  3  : ■  chf 
read(atfilef  ch)| 
k  :«  k  +  1 
end  l 

while  (k  <  21)  do 
begin 

atrtemp'". identif ierCkl  :■  ' 
k  !»  k  +  1 
end  I 

atrtemp'".pointer  :■  nil) 
atrptr  :■  at r base I 

C  See  if  attribute  already  in  list  keyed  on  attributes  > 
while  < (atrptr'".atrname  <>  atrtemp'". identifier) 
and  (atrptr^.pointeratr  <>  nil))  do 
atrptr  : ■  atrptr"".pointeratr  | 


if  (atrptr'".atrname  «  atrtemp'".  identifier) 
then  relteep  :■  atrptr^.pointerrel 

f  Already  in  list  > 

else 

begin 

atrptr'". atrname  :■  atrterap"".  identifier  f 

{  Now  its  in  list  > 

write  (atrptr'".  atrname)  |  {  Output  to  user  > 

break (output) 
end) 


if  atrptr"".  pointerrel  ■  nil 

then  C  Put  relation  name  in  list  keyed  on  attributes  > 
begin 

new  (atrptr'".  pointerrel )  I 
reltemp  :■  atrptr"".  point  errel  I 
rel temp'". pointer  : ■  nil l 
reltemp'".  identifier  :  ■  rel  ptr'".  rel  name 
end 

else 

begin 

while  (rel temp"'. pointer  <>  nil)  do 


relteoip  :■  rel  temp‘d,  pointer) 
new  (relte<npA.  pointer) ) 
r el  temp  : ■  reltemp^. pointer) 
reltemp^. pointer  :■  nil  I 
reltemp-'. identif ier  :■  relptrA.relname 
end) 

for  i  :■  1  to  3  do  readln (atf i la,  ch)) 

<  Skip  sort  info  > 

if  (ch  -  ’N’ ) 

than  constraint  :«  falss  <  Constraint  dsfinsd  ?  > 
else  constraint  : ■  true} 

if  constraint  <.  Skip  constraint  info  > 

than  for  i  :■  1  to  2  do  readln (atf ile,  ch)j 

read (atf ile,  ch)| 

<  Eithsr  rsad  *  for  and  of  ralation  definition, 
or  first  1 attar  of  anothar  attribute  > 
if  (ch  -  ) 

than  ralationand  : ■  true 
alsa  ralationand  : *  falsal 

if  ralationand 
than 

bagin  (  Skip  password  saction  > 

read (atf ile,  ch) I 

whila  (ch  <>  **’)  do  raadln(atfila,  ch)| 
for  i  :■  1  to  7  do  raadln (atf i la,  ch)| 
read (atf i la,  ch)) 

C  Eithar  raad  *  for  and  of  databasa  definition, 
or  first  latter  of  new  ralation  name  > 
if  ( (ch  ■  '  *’)  and  not  eof(atfile)) 
than 
bagin 

whila  not  eof (atfila)  do  read (atf i la,  ch)| 
atrtemp^. pointer  S«  nil 
end 

else 

if  (ch  <>  '*’) 
than 
bagin 
k  S»  1| 

new (reiptr^.rel pointer) ) 

<  Bat  ready  for  anothar  ralation  name  in  ralbasa  list  > 

ralptr  :■  relptr^.relpointer I 
relptr"'.  rel  pointer  :■  nil  I 
naw(relptr^.atrpointar) I  > 
at r temp  : «■  relptr'*. at r pointer ) 
whila  (ord (ch)  <>  13)  do 

C  Put  ralation  name  in  list  > 

bagin 

ralptr^.ralnaflMiCkl  :■  ch) 
raad (atfila,  ch)) 
k  k  +  i 


fcV  VjSj  while  <k  <  21)  do 

begin 

relptr''.  relnameCkl  :»  '  ’ I 
k  :*  k  +  1 
end) 

read(atfile,  ch)  y 

i  Get  rid  of  line  feed  > 
read(atfile,  ch) 

<  Get  first  letter  of  attribute  > 

end 

end  | 

if  not  relationend 
then 
begin 

new  (atrtemp''.  pointer) I 
atrtemp  :*  atrtemp''. pointer I 
while  (atrptr"'.pointeratr  <>  nil) 
do  atrptr  :■  atrptrA.pointeratr| 

C  Get  to  end  of  list  > 

new  (atrptr"'.  pointer atr) I 
atrptr  : “  atrptr''. pointer atrj 
atrptr"'.  pointer  atr  :■  nil| 
atrptr"*. pointerrel  :■»  nil 
end 

end  I 

C  THE  FOLLOWING  SECTIONS  ARE  FOR  DEBUGGING  USE  > 

<  THIS  SECTION  PRINTS  RELATION  NAME  AND  ATTRIBUTES 

FROM  RELATION  BASED  LIST  > 

{  relptr  :■  relbasei 
while  (relptr  <>  nil)  do 
begin 

atrtemp  : ■  relptr"*.atrpointer | 
writeln ('RELATION' ) » 
writeln (relptr"*.relname> | 
break (output) | 
while  (atrtemp  <>  nil)  do 
begin 

writeln  (atrtemp"*.  identifier ) I 
break (output) | 
atrtemp  : »  at  rf-mp"*.  pointer 
end  | 

relptr  : ■  r el ptr^.rel pointer 
end)  > 


<  THIS  SECTION  PRINTS  OUT  ATTRIBUTES 

FROM  ATTRIBUTE  BASED  LIST  > 

<  atrptr  : ■  atrbase) 
while  (atrptr  <>  nil)  do 


writeln  (atrptr'-'.atrname,  ’  Z' )  t 
break (output) \ 

atrptr  atrptr"*.  pointer  atr 

end  | 

break (output)  > 
endf 
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<*********#*#*###**#*#*###**#***##***####* 

*  DATE:  3  Aug  83  * 

*  MODULE:  Request id  * 

*  FUNCTION:  Gats  ussr  nams.  * 

*  INPUTS:  non*.  * 

*  OUTPUTS:  ncxis.  * 

*  LOCAL  VARIBLES:  i,  ch,  nams  * 

*  GLOBALS  USED:  linss  * 

*  MODULES  CALLED:  clsarlinss  * 

*  CALLED  BY:  main  * 

*  AUTHOR:  VanKirk  * 


######****##*#*#*#####*####*****#****#***> 
procsdurm  rsqusstid; 


i  :  integer | 
ch  :  chart 

nan*  :  short)  <.  For  future  uss  in  databass  sscurity  > 

bog  in 

writsln  (’Welcome  to  thm  Natural  Qusry  Intsr-f ace* )  | 

writsln) 

brsak (output)  I 

writsln (’PLEASE  END  ALL  INPUTS  WITH  A  RETURN' ) y 

writsln) 

brsak (output) y 

writ sin (’Enter  your  last  nams* ) y 
linss  : ■  1 1 y 
clsarl inssy 

for  i  :■  1  to  IS  do  namsCil  :■  *  'y  (  Clsar  nams  > 

i  :-  ly 

whils  (i  <  16)  do  (  Oat  nams,  stop  on  full  nams  > 

bsgin 

rsad (ch) y 

if  (ord(ch)  ■  10)  than  i  : ■  17)  (  Stop  on  <CR>  > 

if  (i  <  16)  then  named!  :*  ch) 
i  :■  i  +  1 
and) 

linss  24) 
clsarlinss) 

writslnCTHIS  IS  IMPORTANT  :  IF  THE  DEFAULT  DRIVE  DOES  NOT’)) 
writsln (’HAVE  ENOUSH  SPACE  FOR  A  SMALL  FILE 

(10  TO  15  BLOCKS) ’)) 

writsln (’THEN  TYPE  LETTER  N. * ) ) 
writslny 

writsln(’IF  YOU  ARE  NOT  SURE,  HIT  ANY  OTHER  KEY  — ’)) 

writsln (’THERE  IS  PROBABLY  ENOUGH  SPACE.’)) 

brsak (output) ) 

linss  :-  9) 

clsarlinss) 

rsadln (ch) y 


*  N*  ) 


if  (ch  - 
than 
begin 

lines  :«  24| 
clearl inesl 

writelnCPut  s  disk  with  some  spac 
in  the  default  drive* >| 
eriteln (*Then  hit  letter  Y* ) | 
break (output)  | 
readln (ch) | 
if  (ch  ■  * Y* ) 

then  continue  :■  true 
else  continue  : ■  false 
end  ' 

else  continue  : *■  true) 
clearl ines 


<<HMHHMMMH»*#**##*##*****##*#*******#*****# 

*  DATE:  3  Aug  83  * 

*  MODULE:  Listinst  * 

*  FUNCTION:  Lists  instructions  on  how  * 

*  to  qusry  ths  database.  * 

*  INPUTS:  none.  * 

*  OUTPUTS:  nons.  * 

*  LOCAL  VARIBLES:  i  ,  eh  * 

*  SL0BAL8  USED:  linss  * 

*  MODULES  CALLED:  clsarlinss  * 

*  CALLED  BY:  sain  * 

*  AUTHOR:  VanKirk  * 

*••••*••**•••••****•*•••••****•*****•••**> 


proesdurs  listinst) 


i  :  i ntsgsr | 
eh  :  char) 

begin 

writsln) 

writeln  ('To  query  a  database, 

a  legal  format  must  be  followed' >| 
break (output) ) 

writeln ('The  rules  of  the  format  follow:')) 

writeln) 

writeln(' 

1.  A  verb  must  be  the  first  word  in  the  query.')) 
writeln ( ' 

(Such  as  LIST,  SHOW,  8IVE,  TYPE,  PRINT)  ')) 
break (output) ) 
writeln) 
writeln(' 

2.  The  rest  of  the  query  must  be  in  sentence  format')) 
writeln(' 

and  use  provided  attribute  names  where  possible.')) 
writeln) 
break (output) ) 
writeln (' 

3.  Specific  attribute  values  must  be  in  quotes.')) 
writeln (' 

Such  as  NAME  «  "Jones"’)) 
writeln) 
break (output) ) 
writeln (' 

4.  You  must  signal  end  of  query  by  ending  with  a  period')) 
writeln) 

break (output) ) 
writeln (* 

5.  The  query  may  not  be  more  than  4  lines  long  (320')) 
writeln (’ 

characters,  including  spaces  and  returns) . ' ) ) 
writeln) 
break (output) ) 


90 


writelnCHit  return  to  continue.*)! 
linos  :■  4| 
clear lines! 
brsak (output) | 

rsad(ch)|  <  Pause  to  1st  usar  rsad  scrssn  > 

linos  24| 
cloarlinosl 

writeln('A  list  o-f  availablo  attributes  follows')! 

writolnf 

break (output) ! 


<*#*#******##****#********#******#**#***** 

*  DATE:  29  Aug  83  « 

*  MODULE:  Fornd ict ionary  • 

*  FUNCTION:  For ns  2  linknd  lists  from  # 

*  files  DATBAS.DIC  and  STD. DIC* 

*  to  set  ss  dictionaries.  * 

*  INPUTS:  none.  * 

*  OUTPUTS:  Linked  lists  with  datbase  and* 

*  stdbase  as  roots.  * 

«  LOCAL  VARIBLES:  i ,  datfile,  stdfile  « 

GL0BAL8  USED:  stdbase,  datbase,  dat-  * 

tenp,  stdtemp  « 

MODULES  CALLED:  clearlines  « 

CALLED  BY:  Main  * 

*  AUTHOR:  VanKirk  « 

*****************************************> 


procedure  formdictionaryy 


var 

i  :  i nteger  y 
datfile,  stdfile 


text! 


begin 

clearlinesy 

writeln ('CREATING  DICTIONARIES’ > I 

break (output) I 

clearlinesy 

nee (datbase) y  C  Bet  root  > 

dat tenp  :■  datbase y 

dat  temp'*.  pointer  :■  nily 

if  (datdrive  ■  *Y*)  (  Ready  file  for  reading  > 

then  reset (datfile,  "DYO: DATBAS. DIC" ,  2) 
else  reset (datfile,  HDY1: DATBAS. DIC",  2) y 

while  not  eof (datfile)  do  C  Read  fron  file  > 

begin 

for  i  :■  1  to  19  do 

read  (datfile,  wordCiDy 

{  For  some  unknown  reason,  read  (datfile,  dat  temp**,  identifier  Ci  3) 
does  not  work  here  —  when  this  nodule  was  inside  PROCESSQRY, 
it  workedy  but  at  this  level,  for  sone  reason,  the  file  is 
found  and  opened,  the  characters  can  be  read  to  a  character 
holder  (I  read  into  ch),  but  assignment  to 
dat tenp identifier Ci I  resulted  in  no  character  transfer. 
Indirection  through  WORD  works  —  lucky  to  find  it.  > 

readln (datfile,  wordC203)y 
dattemp^. identifier  :■  wordy 

if  eof (datfile)  <  If  done,  terminate  list  > 

then  dattemp's. pointer  :■  nil 


new (dat temp", pointer)  | 

{  Not  done,  got  another  box  > 
dattmp  : ■  dat temp". pointer 
end 

end! 

new(stdbase) y  <  Saee  comment a  (and  code)  as  above 

stdtemp  : ■  stdbasey 
stdtemp". pointer  :■  nili 

if  (stddrive  -  ’Y’) 

then  reset (stdfile,  "DYOsSTD.DIC",  2) 
else  reset (stdfile,  HDYl:8TD.DICH,  2) I 

while  not  eof (stdfile)  do 
begin 

for  i  :■  1  to  19  do 

read (stdfile,  wordCi3)y 
readln (stdfile,  wordC203)| 
stdtemp'*. identifier  :■  word! 
if  eof (stdfile) 

then  stdtemp". pointer  :■  nil 
else 
begin 

new (stdtemp". pointer) | 
stdtemp  :■  stdtemp". pointer 


<*******###***###**#****#*#***#***#**#**#* 

*  DATE:  11  Aug  83  * 

*  MODULE:  6* t word  « 

*  FUNCTION:  Bat*  naxt  word  for  trana-  * 

*  1 at ion  out  of  array  quary.  * 

*  INPUTS:  non*.  * 

*  OUTPUTS:  word  * 

*  LOCAL  VARIBLES:  i,  k  * 

*  QL0BAL8  USED:  j,  langth,  quary,  word,  * 

*  andquary  * 

*  MODULES  CALLED:  non a.  * 

*  CALLED  BY:  Procassqry,  translata,  * 

*  algabra,  find quo tad,  find-  * 

«  logical,  f indattributa  * 

*  AUTHOR:  VanKirk  « 


#*##*******#**##*##**#***#*•***#•**•**#**•***> 

procadura  gatwordl 

var 

i,  k  :  intagar | 

bagin 
i  :«  li 

whila  ((quarytjl  ■  ’  ' )  and  (j  <>  langth))  do  j  : ■ 
whila  ((quaryCjl  <>  *  ' )  and  (J  <  (langth  +  1)))  do 
bagin 

wordCil  :■  quaryCjlj 
i  :«  i  If 
j  :-  J  ♦  1 
and  | 

if  (J  >■  langth)  than  andquary  : ■  truai 
for  k  :■  i  to  20  do  wordCkl  !■  '  ’ 


j  ♦  1» 


«  DATE:  16  Aug  83  « 

*  MODULE:  Checkattribute  * 

*  FUNCTION:  Looks  -for  word  in  attribute  * 

*  dictionary.  • 

*  INPUT8:  gotword.  * 

*  OUTPUTS:  word,  gotword  # 

*  LOCAL  VARIBLES:non».  « 

*  GLOBAL S  USED:  word,  gotword,  atrbass,  * 

*  atrptr  * 

*  MODULES  CALLED: non s.  * 

*  CALLED  BY:  Translate,  algsbra,  -find-  « 

*  attribute  « 

*  AUTHOR:  VanKirk  * 

***************»**«4HHMHMMMMMMMHHHHHMM|.«*«} 

procedure  checkattribute<var  gotword  :  boolean)! 
begin 

atrptr  :■  atrbasei 

while  < (atrptr  <>  nil)  and  (not  gotword))  do 

(  Go  to  attribute  keyed  list  > 
i-f  (atrptr^.atrname  ■  word)  €  So  to  correct  attribute  > 
then 
begin 

gotword  :-  true!  <  Found  it'!  > 

word  :■  atrptr atrname 
end 

else  atrptr  :•  atr ptr pointer atr 

end! 


mm 


« ■ 


<•***»•**•*•••*»****#**»****«*******•***»* 


*  DATE:  11  Aug  63  * 

*  MODULE:  Procattqry  * 

*  FUNCTION:  Ovaritti  translation  o-f  * 

*  query  to  intermediate  -fora.  * 

*  INPUTS:  nona.  * 

«  OUTPUTS:  quary.  * 

*  LOCAL  VARIBLES:  nona.  * 

*  8L0BAL8  USED:  query,  j,  nq,  and quary,  * 

*  call  translate,  new query,* 

*  length  * 

«  MODULES  CALLED:  getword,  translate.  * 

*  CALLED  BY:  Recvqry  * 

*  AUTHOR:  VanKirk  * 

»♦»»♦»♦»»»»»»»»♦»»»»»»♦»♦»»»»»»»»»»»»♦♦»»> 


procedure  procassqryl 


<*#*<MHHMMM»**##*#*###*******#***#***#***** 


* 

late:  11 

Aug  83 

* 

* 

module: 

Transl ata 

* 

• 

FUNCTION:  Chacks  quary  word-by-word 

* 

* 

against  dictionarias. 

* 

• 

INPUTS: 

none. 

* 

* 

outputs: 

word 

* 

* 

LOCAL  VARIBLE8:  i,  gotword,  thisfiie. 

* 

* 

got quotas,  savait 

* 

* 

QLOBALS 

USED:  word,  cal 1 transl ata,  j 

* 

# 

MODULES 

CALLED:  check word,  check- 

* 

« 

attribute,  getword. 

« 

* 

putword 

* 

« 

CALLED  BY:  procassqry 

« 

* 

AUTHOR: 

VanKirk 

• 

procedure  translate! 
var 

got word,  got quotas  :  boolaani 
this-fila  :  text! 
i  :  intagar | 
savait  :  short i 


<#*#******#****#*****#*******#**#********* 

*  DATE:  11  Aug  83  * 

*  MODULE:  Check word  * 

*  FUNCTION:  Looks  for  word  in  database  * 

*  and  standard  dictionaries.  * 

*  INPUTS:  gotword.  « 

*  OUTPUTS:  word,  gotword.  * 

*  LOCAL  VARIBLES:  found,  ussptr  * 

*  6L0BALS  USED:  word  * 

*  MODULES  CALLED: none.  « 

*  FILE  READ:  DATBAS.DIC,  STD. DIC  * 

«  CALLED  BY:  translate  # 

*  AUTHOR:  VanKirk  * 


a***************#***#****#***************} 

procedure  checkword (var  useptr  :  -"list!  var  found  :  boolean)! 
var 

begin 

while  (useptr  <>  nil)  do 
begin 

if  (useptr*".  identifier  «=  word) 
then 
begin 

useptr  : *  useptr^. pointer! 
word  : ■  useptr*". identifier! 
found  : ■  true! 
useptr  : ■  nil 
end 
else 

useptr  : ■  useptr'". pointer''. pointer 

C  Skip  next  word  > 


<*************************#*************** 

*  DATE:  29  Aug  63  * 

*  MODULE:  Put word  * 

*  FUNCTION:  Puts  word  -found  in  die-  * 

*  tionary  in  the  new  query.  * 

*  INPUTS:  none.  * 

*  OUTPUTS:  n aw quary.  * 

*  LOCAL  VARIBLES:  i ,  apacacount  * 

*  6L0BALS  USED:  nawquary,  nq,  word  * 

*  MODULES  CALLED:  nona.  * 

*  CALLED  BY:  Translate  * 

*  AUTHOR:  VanKirk  * 

******************«******«***************} 


procedure  putwordl 
var 

if  spacacount  :  integer) 
begin 

spacacount  :»  0) 
i  :-  li 

while  <<i  <  21)  and  (spacacount  02))  do 

{  Allow  two  words  separated  by  one  space  -for  word  > 

begin 

if  < (wordCi 3  «  '  ’)  and  (wordCi  ♦  13  -  '  ’)) 
then  spacecount  :■  2| 

newqueryCnql  :■  wordCi 3)  C  Put  word  in  query  > 

i  :■  i  +  If 

if  (nq  <  320)  then  nq  :■»  nq  +  1 
end 


end) 


>gin  <  *************  TRANSLATE  ************  > 

cal ltr ansi at*  :*  cal ltr ansi at*  1) 

got  quotas  :  ■  -falsa)  {  Flag  specific  valuas  > 

if  (cal ltr ansi ata  *  1) 
than 
begin 

got word  : *■  falsa) 
stdtemp  : *  stdbasa) 
chackword (std tamp, got word) ) 

if  not  gotword  t  Not  a  known  word  > 

then 
bagin 

savait  :■  word)  <.  Replace  with  LIST  > 
word  'LIST  ’) 

putword) 
word  : ■  savait) 
checkat tribute (got word) 
end 

end 

else 

bagin 

if  (wordCll  -  »•') 

C  Words  (up  to  2)  in  quotes  are  specific  valuas  > 
than 
begin 

gotword  : =  true) 
got  quotas  true 
and 

else  gotword  :«*  false) 

if  not  gotword  than  checkattribut* (gotword) ) 

<  Is  it  attribute?  > 

if  not  gotword 
than 
begin 

dattaap  !■  da t base) 
chackword (dat tamp,  gotword) 

{  Is  it  attribute  alias?  > 

and) 

if  not  gotword 
than 
begin 

stdtaap  :■  stdbasa) 

<  Look  in  standard  dictionary  > 
chackword (stdtemp,  gotword) 
end 

and) 

if  gotword 
then 
bagin 

putword) 
if  got quotes 
then 


*  j  ♦  ll 

while  < query Ci 3  O'  * )  do 

<  See  if  only  one  word  in  quotes 

begin 

if  query Ci  3  -  ’  ’ 

then  gotquotes  :■  true 
else  gotquotes  : ■  false* 
if  gotquotes 
then 
begin 

get word | 
putword 
end  | 

i  :•  i  +  1 


bigin  <  ***********  PROCESSOR V  ***********  > 

-for  nq  :■  1  to  320  do  newqueryCnql  :■  trash | 

(  Fill  with  unlikely  char  > 

end query  :■  false) 

j  :■  ll  {  Counter  for  query  array  > 

nq  :■  1|  {  Counter  for  newquery  array  > 


cal ltr ansi ate  :■  0| 

<  Count *r — typs  flag  set  to  look  for  verb  > 
while  not  and query  do 
bsgin 

got word | 
translate 
end  | 

nq  :■  nq  —  1|  (  nq  points  past  and  of  query  > 

if  (newqueryCnql  ■  '  *)  than  nq  : ■  nq  -  1| 

<  If  last  character  of  nawquary  blank, 
no  sense  in  keeping  it  > 

query  : ■  new query) 

{  Save  translated  query  in  global  area  > 

length  :■  nq 
end  | 


{••**••****•***•********«*•«***#*•**••**** 
«  DATE:  3  Aug  63  * 

«  MODULE:  Recvqry  * 

*  FUNCTION:  Lets  umt  insert  query.  * 

*  INPUTS:  i  -  start  marker  to  array.  * 

*  OUTPUTS:  array  query  * 

*  LOCAL  VARIABLES:  ch,  k  * 

*  GLOBALS  USED:  query,  length,  lines  * 

*  MODULES  CALLED:  changeqry,  clearl ines, * 

*  processqry  * 

*  CALLED  BY:  main,  changeqry  * 

*  AUTHOR:  VanKirk  * 

•*•**•*•**•*•••*****••****»»*•«•*********> 


procedure  recvqry(var  i  :  integer) | 

£  Counter  for  where  to  start  in  in  array  query  > 

var 

k  :  integer!  £  Counter  for  query  length  > 

ascii  :  integer!  £  Decimal  equivalent  of  ascii  > 

ch  :  char! 

begin 

if  (i  -  1) 
then 
begin 

writeln! 

wr i tel n(’ Input  query  (end  with  .):*)! 
break (output) 
end! 
k  :■  i  i 

while  (i  <  321)  do  <  Receive  the  query  > 

begin 

read (ch) ! 

ascii  : ■  ord(ch) ! 

if  ((ascii  <  33)  or  (ascii  >  90))  then  ascii  : ■  36! 

(  Unwanted  characters  > 

if  (((ascii  >  47)  and  (ascii  <  58))  or  ((ascii  >  64)  and 
(ascii  <  91)))  then  ascii  : ■  65! 

£  Numbers  and  capital  letters  > 

case  ascii  of 

33,  34,  35,  3B,  42,  43,  45,  46,  47,  60,  61,  62,  65:  ! 

£  Save  numbers,  letters,  operators,  and  special  symbols  > 
36,  37,  39,  40,  41,  44,  58,  59,  63,  64:  ch  :«  *  *1 

£  Toss  out  unwanted  characters  > 

end! 

if  (ch  “  ender) 

£  Stop  at  .  since  <CR>  can  happen  many  times  > 

then 

begin 

i  :«  350! 
readln (ch) 
end! 


1 


if  <i  <  321)  than  query! i 3  :■  ch) 

(  Sava  only  320  charactars  > 
k  :■  k  ♦  1|  i  Count  charactars  > 

i  i  ♦  1 
and  I 

k  :■  k  -  2)  <  k  points  ona  spot  past  andar  > 

langth  :■  k)  <  langth  points  at  last  1 attar  > 

procassqry |  €  Taka  quary  to  intermediate  form  > 

wri tain (' This  is  tha  quary  as  understood: ') I 
writelni 
braak (output)  I 

for  i  :■  1  to  langth  do  wri te(queryCi D) | 

{  Ignore  screen  and  while  outputting  quary  > 

break (output) ) 
writelni 
writelni 
break (output)  i 

write (’Is  it  correct?  Answer  Y  or  N: ’ ) i 
braak (output)  i 
readln (ch)  i 
i-f  (ch  -  *  N’ ) 

than  changeqry  (  Spring-loaded  to  accept  quary  > 

else 
begin 

lines  24) 

claarlinas) 

wri tain (’PROCESSING  YOUR  QUERY’)) 
break (output ) ) 
lines  12) 

claarlinas 
and 

end) 
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i 

« 

* 

* 


* 

* 


'*#*##**#**#**#*#####***###****#*****#*# 
DATE:  3  Aug  83  * 

MODULE:  Changeqry  * 

FUNCTION:  Allow*  user  to  *dit  th*  * 


qu*ry.  * 
INPUTS:  non*.  * 
OUTPUTS:  qu*ry  * 
LOCAL  VARIBLES:  find,  i,  j ,  ch,  don*,  • 

count  * 
8L0BALS  USED:  query,  J  « 
MODULES  CALLED:  recvqry  * 
CALLED  BY:  recvqry  * 
AUTHOR:  VanKirk  * 


a**#******##****#***###**#*#***#*###***#*! 


proc*dur*  changeqry  y 
var 

find  :  packad  array Cl.. 801  of  chart 

{  String  indicating  wh*r*  chang*  start*  > 
i ,  jf  count  :  int*g*r| 

<  i  stops  thru  find,  j  thru  qu*ry  count 
has  numb*r  char act *rs  in  find  > 

ch  :  chart 
don*  :  bool*ani 

b*gin 

writelnl 

writelnl* Input  a  string  of  characters  uniquely  identifying* ) I 
break (output) | 

writeln(*the  part  of  th*  query  you  want  to  change.  Maximum’ ) I 
writeln(* length  of  the  string  is  one  line  (80  characters) . ’ ) | 
writelny 
break (output) I 

wri teln ( *  THE  QUERY  WILL  BE  OVERLAID  STARTING  AT  THE  FIRST*)! 
wri teln (’CHARACTER  YOU  INPUT. *) I 
writelnl 
break (output)  I 

wri  teln  (’  Input  string  (end  with  <CR»:*)I 

writelnl 

break (output)  I 

for  i  :■  1  to  80  do  find Cil  : ■  trashy 

(  Fill  with  unlikely  character  > 

read (ch) y 
i  :■  ly 

while  (ord(ch)  <>  10)  do  C  Stop  reading  on  <CR>  > 

begin 

if  (i  <  81)  then  findCil  :-  chy 

i  :-  i  +  ly 
read (ch) 
endy 


count  :■  Oy 


while  ( (f indCi 3  <>  trash)  and  (i  <  81) )  do 
bsgin 

count  : *  count  +  1| 

{  Count  nueber  of  characters  in  find  > 

i  i  +  1 
end) 


j  li 
i  :«  li 

done  : ■  false! 


while  not  done  do 
begin 

if  (findCil  ■  queryCjl) 

C  Locate  string  in  query  held  by  find  > 
then  i  :«  i  +1 
else  i  S-  1| 


J  J  ♦  il 

if  <(i  -  1)  ■  count)  then  done  : *  true 
•ndl 


i  Found  string  > 


j  j  -  count | 

f  j  points  at  first  character  in  find  string  > 

writelni 

writeln (* Input  changes  (end  with  .):')! 

writelni 

break (output)  I 

recvqry ( j ) 


<•*••**««•*#*»•*»*****#*********«****•**** 


*  DATE:  31  Aug  83  * 

*  MODULE:  Algebra  * 

*  FUNCTION:  Transforms  intermediate  form* 

*  of  query  to  relational  * 

*  algebra.  * 

*  INPUTS:  none.  * 

«  OUTPUTS:  See  FILES  WRITTEN.  » 

*  LOCAL  VARIBLES:  attribute,  done,  * 

*  doubl eparen,  quoted,  * 

*  lastfile,  relation,  * 

*  logical,  operator,  * 

*  ophol der  * 

*  8L0BALS  USED:  word,  j,  relbase,  relptr* 

*  MODULES  CALLED:  Findquoted,  select,  * 

*  get word,  join,  check-  * 

*  attribute,  project,  * 

*  all used  * 

*  FILES  WRITTEN:  QRYTMP.TMP  * 

*  CALLED  BY:  Main  * 

«  AUTHOR:  VanKirk  * 

»»»»»*♦»»»»»»»»»»»»»«»«»»»«»»»♦»♦♦♦»»»»»»> 


procedure  algebrai 


attribute,  done,  doubl eparen, 
logical,  operator,  quoted  :  boolean! 

{  Flags  to  track  format  of  algebra  > 

lastfile  :  text l 

C  Temporary  file  created  until  user  makes  final 
decision  on  whether  to  keep  query  > 
relation  :  packed  array Cl.. 33  of  charl 

(  Made  up  relation  names  for  join,  select,  and 
project  operations  > 

ophol der  :  char | 

<  Holds  one  character  relational  algebra 
operator  > 


{a**************************************** 
»  DATE:  2  Sap  83  * 

*  MODULE:  Natural  * 

«  FUNCTION:  Changas  variabla  RELATION  * 

*  to  aake  new  relation  name. 

*  INPUTS:  none. 

*  OUTPUTS:  relationC23  changas. 

*  LOCAL  VARIBLES:  none. 

*  0LOBALS  USED:  relation 

*  MODULES  CALLED:  none. 

*  CALLED  BY:  Join,  select 

*  AUTHOR:  VanKirk 

*#***************************************> 

procedure  neutral | 
begin 

relationC21  : ■  succ (relationC23) 


<***#********#**##***##*#******#**#******* 


«  DATE:  5  Sap  83  * 

*  MODULE:  Putfila  * 

*  FUNCTION:  Writaa  singla  word  to  fill  * 

*  QRYTMP.TMP  by  way  of  lamt-  * 

*  fila.  # 

*  INPUTS:  Naaait.  * 

*  OUTPUTS:  Saa  FILE  WRITTEN.  * 

«  LOCAL  VARIBLES:  i,  naaait.  « 

*  BLOBALS  USED:  lastfila  * 

*  MODULES  CALLED:  nona.  * 

*  FILE  WRITTEN:  QRYTMP.TMP  * 

*  CALLED  BY:  Dowhara,  projact,  join  * 

*  AUTHOR:  VanKirk  * 


a*####****##*#**#**#***####*****##**##**#} 


procadura  putfila (naaait  :  short) f 


var 

i  :  intagari 

bagin 
i  :-  li 

whila  (<i  <  21)  and  (naaaitCil  <> 
bagin 

writadaatf  ila,  naaaitCil)| 
i  :-  i  +  1 


’  ’>>  do 


<#*******#**#•***•*******************•**** 

*  DATE:  5  Sop  S3  * 

*  MODULE:  Allusad  * 

«  FUNCTION:  Sn  if  all  relations  have  * 

*  bwn  u«td  in  JOIN.  * 

«  INPUTS:  none.  * 

*  OUTPUTS:  boolean.  * 

*  LOCAL  VARIBLES:  notusad  * 

*  6L0BALS  USED:  ralbama  * 

*  MODULES  CALLED:  nona  * 

*  CALLED  BY:  Join  * 

*  AUTHOR:  VanKirk  * 


**#***«**********»«**********************} 

function  allusad  :  boolaani 

var 

notuaad  :  ''iistreli  t  Pointar  to  ralation  list  > 

bag  in 

notusad  :■  ralbasai  f  Start  at  top  of  list  > 

whila  ((notusad  <>  nil)  and  (notusad'"'.  used  ■  *Y’)) 
do  notusad  : ■  notusad''. ral pointar) 
if  (notusad  ■  nil) 

than  allusad  :■  trua  (  All  relations  usad  > 

alsa  allusad  : ■  falsa 

end) 
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c ***************************************** 
«  DATE:  9  Sep  83  * 

»  MODULE:  Join  * 

*  FUNCTION:  Creates  relational  algebra  * 

*  JOIN.  « 

*  INPUTS:  latest  -  Last  relation  created* 

«  OUTPUTS:  See  FILE  WRITTEN  * 

*  LOCAL  VARIBLES:  current*  gorel ,  match  * 

*  GL0BAL8  USED:  last-file*  word*  atrtemp** 

*  r el temp  * 

*  MODULES  CALLED:  Betptr*  attlist*  new-  * 

*  rel ,  addto*  putfile  * 

*  FILE  WRITTEN:  QRYTMP.TMP  * 

*  CALLED  BY:  Algebra  * 

*  AUTHOR:  VanKirk  * 

*****************************************> 


procedure  joinCvar  latest  :  short) | 


var 

gorel  * 


current  :  ^listrell 
match  :  bool eani 


Pointer  to  unused  relation  found 
with  same  attribute  in  it  > 

Pointer  to  result  of  last  join  > 
Tells  if  found  a  relation  that  is 
not  yet  used  in  join  AND  has  an 
attribute  in  common  with  CURRENT  > 


<***************************************** 
«  DATE:  S  Sep  83  * 

*  MODULE:  Betptr  # 

*  FUNCTION:  Gets  a  pointer  in  relation  * 

*  list  that  points  to  relation* 

*  naeed .  * 

*  INPUTS:  Findrel,  return  * 

*  OUTPUTS:  Return  * 

»  LOCAL  VARIBLES:  none.  * 

*  3L0BALS  USED:  r el base  * 

*  MODULES  CALLED:  none.  * 

«  CALLED  BY:  Join  * 

*  AUTHOR:  VanKirk  * 


a****************************************} 

procedure  getptr i-f indrel  :  short!  var  return  :  Alistrel)| 

begin 

return  :»  r el  base! 

while  (return^.relname  <>  f indrel) 
do  return  :■  return''. relpointer 


£ 


{*****«*******«*****************##**»****# 


*  DATE:  5  Sap  83  * 

*  MODULE:  Attlist  * 

*  FUNCTION:  Looks  thru  attribute  list  * 

*  -for  attribute  SENTP  then  * 

*  returns  pointer  to  a  * 

*  relation  that  has  SENT  * 

*  attribute  in  it.  If  that  * 

*  attribute  can't  be  found,  * 

*  moves  pointer  SENT  to  next  * 

*  attribute,  and  looks  for  it.* 

*  INPUTS:  none.  * 

*  OUTPUTS:  thatptr  * 

*  LOCAL  VARIBLES:  thisptr  « 

*  6L0BALS  USED:  atrbase,  at r temp,  rel-  * 

*  temp  * 

*  MODULES  CALLED:  none.  * 

*  CALLED  BY:  Join  * 

*  AUTHOR:  VanKirk  * 


*****************#*******#***************} 


! 


P 


procedure  attlisti 
var 

thisptr  :  "'list  atr)  {  Pointer  to  attribute  list  > 

begin 

if  (rel temp  ■  nil) 

CNil  indicates  haven't  found  common  attribute  yet  > 

then 

begin 

thisptr  :-  atrbase)  €  Start  at  top  > 

while  ( (atr  temp"',  identifier  <>  thisptr"''.  at  r  name) 
and  (thisptr  <>  nil)) 
do  thisptr  :■  thisptr"'. pointer atr) 

<  Try  next  attribute  in  attribute  list  > 
if  (thisptr  ■  nil) 

then  {  Look  for  next  attribute  from  list  > 

begin 

atr  temp  :  *  atr  temp"',  pointer) 
attlist 


if 


end) 


end 

else  reltemp  :■  thisptr"'. pointerrel 

{  Found  a  relation  with  this  attribute  > 

end 

else  reltemp  :■  rel  temp"',  pointer) 

<  Last  relation  name  sent  back  was  already  used  > 
(reltemp  ■nil) 

then  {  No  more  relations  have  this  attribute  > 

begin 

atr  temp  :■  atr  temp"',  pointer) 
attlist 
end 
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j-s  aw  ,v>v 


<* 

** 

* 

date:  5 

Sep  83 

* 

* 

module: 

Addto 

* 

* 

FUNCTION:  Adds  relation  named  to  list 

* 

* 

of  relations,  and  makes  it 

* 

* 

"used"  for  JOIN  purposes. 

* 

* 

INPUTS: 

Rell,  rel2 

* 

* 

OUTPUTS: 

none. 

* 

* 

LOCAL  VARIBLES:  add,  addrel,  puthere. 

* 

* 

addit 

* 

* 

GLOBALS 

USED:  relbase,  relation 

* 

* 

MODULES 

CALLED:  getptr 

* 

* 

CALLED  BY:  Join 

* 

* 

author: 

VanKirk 

* 

> 


procedure 


var 

add, 

addrel  : 


addto(rell,  rel2  :  short); 

£  Rell  and  rel2  are  relations  joined  to 
produce  current  relation  name  created  > 


f  Pointer  to  rell/rel2  name  in  relation  list  > 
<  Pointer  to  end  of  relation  list,  where 

relation  is  added  > 


A1 istrel ; 


puthere,  £  Pointer  to  attribute  list  of  addrel 

where  attributes  are  being  added  > 
addit  :  £  Pointer  to  rell/rel2  attribute  > 

"'‘list; 


begin 

getptr(rell,  add) I  €  Get  pointer  to  first  relation  > 


addrel  : =  relbasel 
while  (addrel A.rel pointer  <>  nil) 
do  addrel  : a  addrel '".relpointer; 
new  (addrel '".rel  pointer) ; 
addrel  :  =  addrel  ''.r  el  pointer; 


(  Move  to  end  of  list  > 
(  Create  a  new  holder  > 
(  Ready  to  add  info  > 


addrel '".r el  name  : =  space;  £  Put  in  relation  name  > 

addrel  A.rel  named  1  :■  relationdl; 
addrel A.relnameC21  :■  relationC23; 
addrel relnameC31  :■  relationC3l; 

addrel ‘‘".r  el  pointer  ;■  nil;  £  Put  new  end  on  list  > 


new  (addrel  at  r  pointer) ; 

i  Op  en  up  new  relation's  attribute  list  > 

puthere  :■  addrel atrpointer ;  £  Set  PUTHERE  > 

addit  : ■  add^.atr pointer;  £  Pointer  to  rell  attributes  > 

puthere'". identifier  :■>  additA. identifier ; 

(  Put  first  attribute  on  list  > 
(  Get  next  attribute  > 


addit 


additA. pointer; 


while  (addit  <>  nil)  do 

€  Put  all  of  rail  attributas  on  list  > 

bagin 

naw (puthara*'. pointar ) I 

(  Gat  raady  for  naxt  attributa  > 
puthara  :■  puthara*'.  pointer  | 
puthara*'.  idantif  iar  :■  addit*'.  idantif  iar| 
addit  :■  addit". pointer  <  Gat  naxt  attributa  > 

and  | 

put her a". pointer  :■  nilf 

<  Temporarily  and  attributa  list  > 
gatptr(ral2y  add))  (  Rail  dona,  gat  pointar  to  rel2  > 

addit  :  ■  add"',  at  r  pointer  I 

while  (addit  <>  nil)  do 
bagin 

puthara  : ■  addrel". atrpointer I 

{  Check  attributas  already  added  for  duplication  > 
while  <  (puthara".  idantif  iar  <>  addit*'.  idantif  ier) 
and  (puthara". pointer  <>  nil))  do 
puthara  : ■  puthara". pointer) 

if  (puthara". idantif iar  <>  addit". idantif iar ) 

than  (  Didn't  have  it,  add  it  > 

bagin 

naw  (puthara''.  pointar)  I 
puthara  :«  puthara*'. pointer | 

puthara''. pointer  :«  nill  (  End  the  list  > 

puthara''.  idantif  iar  :  ■  addit''.  idantif  iar 
and) 

addit  : ■  addit''. pointar 
and  I 


addrel".used  :■  *Y 
d  | 


(  Make  relation  "used"  > 


sag in  <  **************  JOIN  ***************  > 
getptr < 1 at  est ,  currant ) I 

{  Find  CURRENT  relation  in  relation  list  > 
atrtamp  :■  currant'". atr pointer ; 

t  Sat  now  to  attributas  > 
current'".used  :■  'Y’;  C  Currant  is  "usad"  in  join  > 

match  : ■  falsa; 

raltaap  :«  nil;  <  Sat  RELTEMP  for  ATTLIST  call  > 

whila  not  match  do 
bag  in 

attl isti 

<  Find  pointar  to  ralation  with  sama  attributa  > 
gatptr  <r el  temp''.  idantif  iar ,  goral )  | 

i  Saa  if  this  relation  is  usad  > 

if  (gorel '".used  -  ’N’) 

than  match  : *  true  (  Wasn’t  usad  > 

end  I 


gorel'".  used  :*  ’  Y’ ; 


{  Usad  now!  > 


writedastf ile,  ’JOIN  '); 

C  Write  relational  algebra  to  QRYTMP.TMP  > 
putf  ile  (current'",  relname)  ;  C  First  ralation  in  join  > 

writedastf  ile,  *,  *)| 

putf  i  le  (gorel'".  relname)  I  f  Second  ralation  in  join  > 

writedastf i la,  *  WHERE  ’); 

putf  ile  (atrtamp''.  identifier )  ;  <  The  attributa  in  common  > 

writedastf  ila,  *  «  ’ )  f 

putf  i  la  (atrtamp'".  identifier)  ; 

newrel!  (  Create  a  name  for  the  resultant  ralation  > 

writeln (lastf ila,  ’  BIVINS  relation); 
latest  : *  space; 

(  Reset  LATEST  to  created  ralation  name  > 
latest Cl 1  :■  relation! 1 I ; 
latest! 21  :«  ralationC2l; 
latest £31  ;■  relationC3l; 


addto  (currant'",  relname,  gorel '".relname) ; 

{  Add  latest  to  relation  list  > 


break (lastf ila) 
•nd; 


<***************************************** 

*  DATE:  31  Aug  63  * 

*  MODULE:  Set err or  * 

*  FUNCTION:  Set  -flags  -for  quick  sxit  o-f  * 

*  program*  and  givm  initial  * 

*  trror  massage.  * 

«  INPUTS:  none.  * 

*  OUTPUTS:  See  QLOBALS  USED  * 

*  LOCAL  VARIBLES:  none.  * 

*  QLOBALS  USED:  attribute, stopprocess,  * 

*  quoted,  logical,  double-* 

*  paren,  done,  lines  * 

*  MODULES  CALLED:  clearlines  * 

*  CALLED  BY:  -f  indlogical  ,  f  in  doper  a  tor ,  * 

*  -find  attribute  * 

*  AUTHOR:  VanKirk  * 


*****•***********************************> 

procedure  seterrori 

begin 

lines  : *  24| 
clearlinesl 
attribute  :■  -false) 
quoted  : ■  false) 
logical  : ■  false) 
doubleparen  :■  false) 
done  :~  true) 
stopprocess  :»  true) 
writeln) 

Mr i tel n <' UNABLE  TO  PROCESS  YOUR  QUERY  DUE  TO  ERROR’)) 
break (output) 


<***************************************** 

*  DATE:  10  Sep  83  * 

*  MODULE:  Findoperator  * 

*  FUNCTION:  Finds  operator  indicating  * 

*  need  to  Croats  SELECT.  * 

«  INPUTS:  nona.  * 

«  OUTPUTS:  findoperator  * 

«  LOCAL  VARIBLES:  i  * 

*  8L0BALS  USED:  query,  j,  length,  * 

*  opholder  * 

*  MODULES  CALLED:  seterror  * 

*  CALLED  BY:  Algebra,  select  * 

*  AUTHOR:  VanKirk  * 


♦♦♦a###*##*###**#***#*#******************! 
function  f indoper ator  :  boolean: 


i  :  integer! 
begin 

i  :■  j|  {  Where  to  start  looking  > 

while  <(i  <>  length)  and  (not ( ( query Ci 3  “  '■’) 

or  ( query Ci 1  -  ’ >* >  or  (queryCil  -  '<’))))  do 
i  :■  i  ♦  1|  {  Find  the  next  operator  > 

if  ((queryCil  *  '■')  or  (query  Ci  3  «*  ’  < ' ) 
or  ( query Ci 3  -  ’  >'  > ) 
then 
begin 

J  :■»  i|  C  Put  j  on  the  operator  > 

f indoper ator  : ■  true! 

opholder  :<■  queryCjl:  (  Save  the  operator  > 

if  ( (query Ci+13  -  ’-’)  or  (queryCi+13  -  ’<’) 
or  (queryCi+1 3  -  '  >' ) ) 
then 
begin 

seterror! 

writeln ( query Ci 3,  queryCi+13, 

’  is  an  illegal  operator.’)! 
writeln (’The  Roth  system  only  allows 
<,  >,  or  -')! 

writeln! 

writeln (’Hit  RETURN  to  continue’); 
break (output) : 
readln (ch) 

end 

end 

else  f indoper at or  :■  false 

end) 


<**#************************************** 

*  DATE:  2  Sep  83  * 

*  MODULE:  Select  * 

*  FUNCTION:  Craatn  relational  algebra  * 

*  SELECT.  * 

*  INPUTS:  none.  * 

«  OUTPUTS:  See  FILE  WRITTEN  * 

*  LOCAL  VARIBLES:  logholder,  value,  * 

*  twowords  * 

*  6L0BALS  USED:  doubleparen,  quoted,  * 

*  last-file,  logical,  * 

*  operator,  ch  * 

*  MODULES  CALLED:  Findlogical,  find-  * 

*  quoted,  dowhere,  * 

*  f indoper ator,  seterror# 

*  FILE  WRITTEN:  QRYTMP.TMP  by  way  of  * 

«  lastfile  * 

«  CALLED  BY:  Algebra  * 

«  AUTHOR:  VanKirk  * 

*****************************************> 


procedure  select I 


logholder  :  packed  arrayC1..33  of  chart 

C  Holds  logical  operator  between  this  quoted 
value  and  next  attribute  > 
value  :  short) 

{  Holds  specified  value  or  attribute  following 
an  operator  > 
t wowords  :  boolean) 

{  True  if  quoted  value  consists  of  two  words  > 


<****************«***********#***#*«****** 

*  DATE:  10  Sep  83  * 

*  MODULE:  Find quoted  * 

*  FUNCTION:  Finds  specific  quoted  value  * 

*  or  attribute  fol lowing  an  * 

*  operator.  * 

*  INPUTS:  none.  * 

*  OUTPUTS:  value  * 

«  LOCAL  VARIBLES:  i,  1,  goodatt  * 

*  SLOBALS  USED:  j,  ch ,  query,  value,  * 

*  two words  * 

*  MODULES  CALLED:  get word,  check-  * 

*  attribute,  seterror  * 

*  CALLED  BY:  Select  * 

*  AUTHOR:  VanKirk  * 

#**#*#****###*#********#*#***#****#**##**> 


function  findquoted  :  bool earn 


var 

i,  1  :  integer | 

goodatt  :  boolean!  {  Indicates  if  word  is  an  attribute  > 
begin 

twowords  : =  false!  <  No  words  in  quotes  yet  > 

value  :■  space!  <■  Clear  value  out  > 

findquoted  :«  false! 
i  :■  j  +  2| 

i  Set  i  to  character  past  blank  following  operator  > 
if  ( query d 1  - 
then 

begin  C  Quoted  value  > 

i  :«  i  ♦  l!  f  Set  past  quote  > 

1  :■  li  <  Pointer  for  value  > 


while  (not  (( query  dl  ■  '  ’ )  or  ( query C i 3  ■  '"')))  do 
begin 

if  <<1  <  21)  and  (i  <  (length  +  1>>> 
then  (  Save  value  > 

begin 

valued  1  :■  query  C  ill 
1  :-  1  +  1 
end! 

i  :-  i  +  1 
end! 


if  (querydl  -  ’  ') 
then 
begin 

twowords  : ■  true! 
valued  1  :«  query C i  3  | 
1  :-  1  ♦  1! 
i  :-  i  II 


<  Two  words  in  quote  > 


while  (not  (( query Ci] 


•  ’> 


or  (queryCil  «■  '"’)))  do 

begin 

if  ((1  <  21)  and  (queryCil  <>  ’ " '  > 
and  (i  <  (length  +  1))) 
than 
bog  in 

valued 3  queryd3) 

1  1  +  1 
end  | 

i  i  +  1 
end 

end  | 

if  <<i  >  length)  or  ((queryCi3  <>  '“’) 
and  (i  <  (length  +  1)))) 
then 
begin 

set error | 

write ('Operator  queryCjl)) 
j  j  +  l* 
get word | 

writeln(*  is  followed  by  ' ,  word)) 
writeln ('Which  has  no  ending  quote')) 
writeln) 

writeln (’Hit  RETURN  to  continue*)) 
break (output) ) 
readln (ch) 
end 

else  findquoted  : ■  true 

end 

lse 

begin 

i  :■  J)  (  Save  j  > 

j  :■  J  +  1)  <  Step  into  blank  after  operator  > 

get word) 

j  i)  <  Reset  j  > 

value  : ■  word)  {  Save  value  > 

goodatt  : ■  false) 
checkattribute(goodatt) ) 

<  See  if  it  is  an  attribute  > 

if  not  goodatt 
then 
begin 

set error ) 

writeln (’Operator  opholder, 

’  is  followed  by  a')) 
writeln (’value  that  is  neither  an 
attribute,  nor  quoted')) 

writeln) 

writeln ('Hit  RETURN  to  continue')) 
break (output ) ) 
readln (ch) 
end 

else  findquoted  :■  true 


u 

* 

DATE:  10  Sap  83 

*** 

**# 

* 

* 

MODULE:  Findlogical 

* 

* 

FUNCTION:  Looks  for 

a  logical  operator* 

* 

f ol lowing 

quo tad  aatarial. 

* 

* 

INPUTS:  nona. 

* 

* 

OUTPUTS:  boolaan 

* 

« 

LOCAL  VARIBLES:  i 

# 

* 

GLOBALS  USED:  j,  word,  logholder. 

* 

* 

two words 

* 

* 

MODULES  CALLED:  gatword 

* 

* 

CALLED  BY:  Sal  act 

* 

* 

AUTHOR:  VanKirk 

* 

«4 

■*** 

##> 

function  findlogical  : 

boolaan) 

var 

i  :  i ntagar I 

begin 

i  :-  j) 

<  j  points 

\  to 

operator  > 

j  :-  j  ♦  li 

{  i  savad 

in 

i ,  move  to  next  word  > 

gatword) 

€  Tha  attribute  or  specified  value  > 

gatword) 

if  twowords 

<  If  last 

value  was  two  words  long  > 

than  gatword) 

{  tha  logical 

is  one  word  farther  > 

if  ( ( (wordCll  -  'A') 

and  <wordC23 

m  9 

NM  and 

<wordC33  -  'DM 

and  <wordt43 

a  » 

' ) ) 

or 

( (wordCll  ■  '0M 

and  (wordC23 

m  9 

R' ) 

and  <wordC33  * 

'  M>> 

than 

{  Found  a  logical  > 

bagin 

findlogical  :* 

true) 

logholderCll  : 

■  wordC13) 

logholder [23  : 

■  wordC23) 

logholderC33  : 

*  word C 3 3) 

c*******#*******«************************* 


*  DATE:  2  Sap  83  * 

*  MODULE:  Do where  * 

*  FUNCTION:  Creates  WHERE  part  of  * 

*  relational  algebra  SELECT.  * 

*  INPUTS:  none.  * 

*  OUTPUTS:  See  FILE  WRITTEN  and  6L0BALS  * 

«  USED.  « 

*  LOCAL  VARIBLES:  operator,  opholder,  * 

*  attholder  * 

*  GLOBALS  USED:  query,  j,  attholder,  * 

*  opholder,  operator,  * 

*  attribute,  lastfile,  * 

*  twowords,  quoted  * 

*  MODULES  CALLED:  f indattribute  * 

*  FILE  WRITTEN:  QRYTMP.TMP,  by  way  of  * 

*  lastfile  * 

*  CALLED  BY:  Select  * 

*  AUTHOR:  VanKirk  * 

•«****•****•*•*••*•*••***********«*#*•***> 


procedure  dowheref 


i  :  i nteger | 
attholder  :  short | 

<  Holds  attribute  associated  with  current 
opholder  and  quoted  value  > 


*  DATE:  1  Sap  83  * 

*  MODULE:  Findattributa  * 

*  FUNCTION:  Looka  -forward  of  oparator  * 

*  in  saarch  of  attribute  to  * 

*  do  SELECT  on.  # 

*  INPUTS:  nona.  * 

*  OUTPUTS:  boolean,  attholder  * 

*  LOCAL  VARIBLES:  find,  k  * 

*  QLOBALS  USED:  query,  j,  attholder,  * 

*  word,  length,  ch,  * 

*  value  * 

*  MODULES  CALLED:  checkattribute,  * 

*  get word,  eeterror  * 

*  CALLED  BY:  Dowhere  * 

*  AUTHOR:  VanKirk  * 

*****«****»***#«******************#******> 


function  f indattribute  :  boolean) 


find  :  bool ean | 

<  Local  holder  to  use  in  calling  checkattribute  > 
k  :  integer) 


begin 

find  : ■  false) 
findattributa  :■  false) 

k  :»  J  -  2)  <  Skip  forward  of  operator,  past  blank 

while  << query Ckl  O'  ')  and  (k  >  i>) 

do  k  :■  k  -  1)  <  Find  beginning  of  word 

i  :■  j  {  Save  j  in  i  since  getword  changes  j 

j  :»  k)  {  Position  j  to  word  wanted 

getword)  <  Global  WORD  now  has  word 

checkattribute <f ind) ) 

<  Check  global  WORD  against  attributes 
j  : ■  i )  C  Restore  j  to  operator 

if  find 

then  i  WORD  has  attribute  in  it 

begin 

attholder  : ■  word) 
findattributa  : ■  true 
end 
else 
begin 

set error ) 

writeln ('Operator  ',  opholder, 

'  is  not  proceeded  by  an  attribute')) 

writeln) 

writeln (’Hit  RETURN  to  continue')) 
break (output ) ) 
readln (ch) 
end 

nd) 


1 

1  x~%J 


gin  i  ************  DOWHERE  ************  > 

i f  quo tad 

than  attribute  :■  find attribute* 
if  attributa 
than 
bagin 

putf ile(attholdar) ?  {  Write  attributa  > 

writadastf  ile,  ’  ' )  t 

writadastf  ile,  opholder,  '  * )  |  C  Writa  oparator  > 
i  li 

whila  ( (i  <  21)  and  (valued]  <>''))  do 
begin 

writadastf  iley  valued  ])  |  t  Writa  value  > 

i  :«  i  +  1 
and  | 

if  two words 
then 
bagin 

writadastf i la,  valued])*  <  Writa  space  > 

i  :«  i  +  li 

whila  <<i  <  21)  and  (valued]  <>  '  '))  do 
bagin 

writadastf  ile,  valued])  I 
i  i  +  1 
and 

and  | 

break (lastfi la) 


.gin  {  **************  SELECT  *************  > 

writ* (last -fils,  ' SELECT  ALL  FROM  ',  relation,  ’  WHERE  ' )  I 

break (lastf ile) ; 

quoted  : ■  find quoted; 

i f  quoted 

then  logical  : =  findlogical; 
if  logical 

then  l  Need  double  parenthesis  > 

begin 

writedastf  ile,  ’(  '); 
break (lastf ile) | 
doubleparen  :■  true 
end 

else  doubleparen  :  =»  false; 
if  doubleparen 

then  C  As  long  as  there  are  logical s, 

put  in  selection  criteria  > 

begin 

writedastf ile,  ’(  *); 
dowhere; 

write (lastf ile,  ■  )  '); 
write (lastf i le,  logholder); 
if  (logholder C33  <>  '  ') 
then  writedastf ile,  '  '); 
while  logical  do 
begin 

j:»j+H  €  Put  j  past  last  operator  > 

operator  : *  f indoper ator; 
if  not  operator 

then  <  Logical  has  no  following  constraint  > 
begin 

set error; 
j  500; 

C  Make  j  to  large  for  further  processing  > 
writeln ('Logical  ',  logholder, 

'  has  invalid  constraint'); 
write(* following  it.  The  constraint  has 
no  operator  ’ ) ; 
writ*ln('(<,  >,  ■)  in  it.'); 
writeln; 

writeln ('Hit  RETURN  to  continue'); 
break (output) ; 
readln (ch) 
end; 

if  (j  <  500) 

then  quoted  :>  find quoted 
else  quoted  : -  false; 
writedastf  ile,  '(  '); 
dowhere; 

writedastf  ile,  '  )'); 
if  quoted 

then  logical  : ■  findlogical; 
if  logical 


write (lastfi la,  *  *)| 
write (lastf ile,  logholder)} 
if  (logholder C33  <>  '  ' ) 
then  writedastf  ile,  '  ' ) 

end 

end} 

write  (last-file,  ’  )  ’>» 

<  End  list  of  constraints  on  attributes  > 

end 

else  dowhere}  <  No  logicals,  only  one  constraint  > 

newrel}  C  Get  new  relation  name  > 

writeln (lastf i le,  ’  GIVING  ’,  relation)} 
break (lastf ile) 
end} 


{ 

# 

* 


« 

* 

* 

* 

* 

* 

* 

* 


DATE:  2  Sept  83  * 
MODULE:  Project  « 
FUNCTION:  Produces  relational  algebra  * 


PROJECT. 

* 

inputs: 

none. 

* 

outputs: 

See  FILE  WRITTEN 

« 

LOCAL  VARIBLES:  i,  more 

* 

SL0BAL8 

USED:  lastf ile,  word 

* 

MODULES 

CALLED:  getword,  check- 

* 

attribute,  putf ile 

* 

FILE  WRITTEN:  QRYTMP.TMP  by  way  of 

* 

lastf ile 

* 

CALLED  BY:  Algebra 

* 

AUTHOR: 

VanKirk 

* 

•#**#*#******##*****> 


procedure  project) 
var 

i  :  i nteger | 
more  :  boolean) 


begin 

more  :■  false) 

writedastf  ile,  *  PROJECT  relation,  ’  OVER  ’>) 
put-f  ile(word)  )  {  Put  attribute  in  relational  algebra  > 

if  (word  <>  'ALL  ') 

then 
begin 

getword)  <  Get  next  word  in  query  > 

checkat tribute (more)  f  See  if  it  is  an  attribute  > 

end) 

while  more  do 

begin  <  Add  on  attributes  until  no  more  > 

writedastf  ile,  ’,  ')) 
putf ile(word) ) 
more  !■  false) 


getword) 

if  (word  -  'AND  ') 

then  getword)  (  Skip  conjunction  in  list  > 

checkat tr i but e (more ) 
end) 

writeln (lastf i le,  * 
break (lastf ile) 


GIVING  NATANS')) 


tgin  €  **************  ALGEBRA  ************  > 

relation  *Z«Z’) 

{  RELATION  £23  gets  character  proceeding  capital  A  > 
rewrite  (last-file,  "QRYTMP.  TMP" )  ) 

<  File  to  store  relational  algebra  in  > 

relptr  :•  relbasef 
while  (relptr  <>  nil)  do 

begin  <  Initialize  relation  linked  list  to 

show  not  yet  used  in  join  > 
relptr''. used  :■  ’N’| 
relptr  :«  relptr^.relpointer 
end) 


relptr  : **  relbasei 
word  :  *  relptr''.relnaee| 

done  :■  -false) 


(  Got  -first  relation  —  hope  the 
rest  is  this  easy  > 


while  not  done  do 
begin 

join (word) ) 

done  :  ■  all  used  {  See  i-f  all  relations  used  in  join  > 
end) 

j  :■  1|  <  Start  at  beginning  of  query  > 

done  : ■  false) 

operator  : ■  f i n doper a tor ) 

{  See  if  user  gave  selection  criteria  > 

if  operator 

then  select)  <  Make  relational  algebra  selections  > 

if  not  done  (  No  errors  found  > 

then 
begin 
j  l) 

getword)  i  Skip  "LIST"  > 

get word ) 

attribute  : ■  false) 
checkattribute (attribute) ) 

if  attribute  l  If  user  did  not  specify  which  attribu' 

then  no  PROJECT  is  needed  > 


then  project 


<*< 

« 

DATE:  24  Aug  83 

* 

* 

MODULE: 

Savaqry 

* 

* 

FUNCTION:  Shows  Ralational  Algabra 

# 

« 

form  of  query  and  gives 

* 

* 

usar  option  of  saving  as  a 

* 

* 

command  fila  for  tha  Roth 

* 

* 

system.  If  saved,  a  file- 

* 

» 

name  is  specified. 

* 

« 

INPUTS: 

Usar  responses. 

* 

* 

outputs: 

Disk  fila. 

* 

* 

LOCAL  VARIBLE8:  i ,  commandfila,  fila- 

« 

# 

name,  ch 

* 

* 

6L0BAL8 

USED:  quary,  length,  lines 

* 

• 

MODULES 

CALLED:  claarlinas 

• 

* 

CALLED  BY:  main 

* 

# 

AUTHOR: 

VanKirk 

* 

*###*#*##***#*#*##**##*****************##> 
procedure  saveqryl 


var 

i  :  integer! 

cowndfilt,  queryfile  :  text| 
f i 1 anaiw  :  packad  array Cl.. 153  of  chart 

{  Usar  mpacifiad  disk  filanama  > 

ch  :  chart 


begin 

reset (queryfile,  "QRYTMP. TMP" ) I 

writelnCThe  Ralational  Algabra  form  of  tha  quary  is:*)| 
writalni 

while  not  aof (quaryf i la)  do 
bagin 

raad ( quaryf i la,  ch)| 
writa(ch) 
and  | 

braak (output) f 
linas  ;»  7| 
claarllnasl 

wri tain ('Would  you  lika  to  sava  it  as  a  command  film? 

(Y  or  N) ' )  | 
braak (output) | 
raadln (ch) I 

if  (ch  <>  ’N*)  C  Spring-loadad  to  sava  quary  > 

than 

bagin  » 

writalni 

wri tain (* Input  disk  filanama  to  sava  quary  in.’)| 
writelnCIf  a  disk  driva  is  not  specified, 
tha  daf ault ' ) I 

writs ('driva  will  ba  usad:  ’ ) | 
braak (output) | 
i  li 


L  TJ 


while  ( (i  <  15)  and  (ord(ch)  <>  10) )  do 
begin 

filenameCil  : ■  ch| 
i  i  +  ll 
read (ch) 
end  I 

f ilenameCi 1  :«  chr(0>| 
rewri te (commandf i le,  filename)! 
reset (queryf ile,  "QRYTMP. TMP") I 
while  not  eof (queryf ile)  do 
begin 

read (queryf i le,  ch)| 
write (commandf ile,  ch) 
end! 

break (commandf i le) 
end! 

ewrite( queryf ile,  "QRYTMP. TMP") 

! 


MAIN  PROGRAM 


> 


<**«* 
begin 

lines  : ■  24|  <  Clear  screen  > 

clearl inesl 
stopprocess  : ■  falsel 
continue  : ■  falsel 
while  not  continue 
do  requestidl 
while  continue  do 

<  Once  in  program,  can  switch  disks  to  keep 
changing  databases  to  build  queries  against  > 

begin 

getdrivesf  <  Find  out  where  dictionaries  are  > 

for edict ionary |  <  Make  the  dictionaries  from  files  > 

lines  :«  24| 

clearl inesl  <  Clear  screen  > 

listinstl  (  Give  instructions  on  how  to  query  > 

getattributesi  <  Show  user  attributes  from  database  > 

if  not  stopprocess 
then 
begin 

J  S"  ll  <  Set  up  new  query  string  > 

recvqry(j)|  {  Reel eve  query  and  change  to 

intermediate  form  > 

algebrai  <  Translate  into  Relational  Algebra  > 
if  not  stopprocess 
then  saveqry 
end  | 

ch  :■  '  '  | 

while  <  <ch  <>  *Y’)  and  (ch  O'N'))  do 
begin 

lines  24| 
cl earl inesl 

writeln(' Would  you  like  to  try  another  query, ') | 
write ('possibly  on  another  database?  (Y  or  N) :  ’) 

break (output) | 
readln (ch) I 
lines  24| 
stopprocess  :■  falsel 
if  (ch  -  ’N') 

then  continue  : - 
clearlines 


falsel 


a 


fTM 


Appendix  I 


MAKDIC  LISTING 


{*********************#********#********** 

*  DATE:  18  Aug  83  * 

*  MODULE:  Makedictionary  * 

*  FUNCTION:  Creates/Adds  to  files  * 

*  STD. DIC  or  DATBAS.DIC.  * 

*  These  files  are  used  by  * 

*  NATQRY  in  query  translation.* 

*  STD. DIC  holds  operators  and  * 

*  "universal"  keywords,  while  * 

*  DATBAS.DIC  is  unique  to  a  * 

*  particular  database.  * 

*  INPUTS:  Requested  interactively.  * 

*  OUTPUTS:  Files  STD. DIC,  DATBAS.DIC  * 

*  LOCAL  VARIBLES:  circle,  ch,  func,  * 

*  name,  word,  i  * 

*  MODULES  CALLED:  none.  * 

*  FILE  READ:  STD. DIC  <if  required).  * 

*  CALLED  BY:  n/a  (incorporate  into  the  * 

*  ROTH  DATABASE  SYSTEM  as  a  * 

*  module  at  a  later  date.)  * 

*  AUTHOR:  VanKirk  * 

**#*******************#«*****»***********> 

program  makedictionary; 


type 

list 


record 

ident  :  array! 1 .. 201  of  char; 
pointer  :  ‘"‘list 
end; 


circle  :  boolean;  C  Loop  checker  to  force  correct  inputs  > 
i  :  integer;  <  Counter  to  step  through  array  word  > 

ch,  C  Utility  character  holder  > 

func,  C  Determines  whether  to  add  to  existing 

dictionary  or  create  new  dictionary  > 
name  :  char;  C  Determines  whether  to  work  on  STD. DIC 

or  DATBAS.DIC  > 

dictionary  :  text;  i  Name  in  this  program  for  file  written  > 

word  :  array Cl.. 201  of  char;  <  The  word  input  to  file  > 

base,  ptr  :  •''list;  <  Pointers  for  manipulating  dictionary 

during  add  information  operation  > 

begin 

circle  :■  true; 


while  circle  do 


C  Get  function  requested  > 


$3 


writeln(’Add  to  or  Create  a  dictionary?  (A  or  C)’); 
break (output ) ;  <  Force  out  writeln  data  > 

readln  (fund  ; 

if  < <f unc  =  *A')  or  (func  =  ’C’)>  then  circle  :=  false 
end; 

if  (func  -  ’ A’  ) 

then  wri teln ( ’ Make  sure  proper  file  is  on  default  drive.’ 
else  writeln (’File  will  be  put  on  default  drive.’); 
writeln; 
break (output) ; 

circle  :  =  true; 

while  circle  do  {  Get  file  requested  > 

begin 

if  (func  =  ’A’) 

then  writeln(’Add  to  Standard  or  Database  dictionary? 
(S  or  D)  ’ ) 

else  wri teln (’ Create  Standard  or  Database  dictionary? 
(S  or  D)  ’ )  ; 

break (output) ; 
readln (name) ; 

if  ((name  =  ’S’)  or  (name  =  ’D'))  then  circle  :*  false 
end; 

if  (func  =  ’C’)  {  Create  a  dictionary  > 

then 
begin 

if  (name  *  ’ S’ ) 

then  rewrite(dictionary,  "STD.DIC",  2); 
if  (name  =  ’ D’ ) 

then  rewr i te ( di ct i onary,  "DATBAS. DIC" ,  2) 

end; 

if  (func  =  ’A’)  C  Add  to  existing  dictionary  > 

then 
begin 

if  (name  =  ’ S’ ) 

then  reset (di cti onary ,  "STD.DIC",  2); 
i f  (name  =  ’ D’ ) 

then  reset (dictionary,  "DATBAS. DIC" ,  2); 

new (base);  C  Read  dictionary  to  save  it  > 

ptr  : =  base; 
ptrA. pointer  :  =  nil; 
while  not  eof (dictionary)  do 
begin 

for  i  :=  1  to  19  do 
begin 

if  not  eof (dictionary) 

then  read (dictionary,  ch); 


ptr"*.  ident Ci  3  :  =  ch 
end; 

if  not  eof (dictionary)  C  Read  end  of  line  > 

then  readln (dictionary ,  ch) ; 
ptr"*. i dent L 20]  :=  ch; 

if  not  eof (dictionary) 
then 

begin  {  Add  to  list  > 

new (ptr'*. pointer  > ; 
ptr  ;=  ptr'*.  pointer ; 
ptr-*.  pointer  :=  nil 
end 

end;  {  Done  reading  dictionary  > 

if  (name  =  'S’ ) 

then  rewrite(dictionary,  "STD.DIC*’,  2) 
else  rewri te (dictionary,  "DATBAS. DIC" ,  2); 

ptr  :  =*  base;  f  Put  info  back  in  dictionary  > 

while  (ptr  <>  nil)  do 
begin 

writeln  (dictionary,  ptr'*.  ident); 
break (dictionary) ; 
ptr  ;  =  ptr'*. pointer 
end 

end; 

circle  :»  true; 

while  circle  do 
begin 

writeln (’ Input  word  to  define’); 
break (output) ; 

i  :=  l; 

read(ch);  <  Get  word  > 

while  (ord (ch)  <>  10)  do  C  Stop  on  <CR>  > 
begin 

wordCil  :*  ch; 
read (ch) ; 
i  :*  i  +  1 
end; 

while  (i  <  21)  do  l  Pack  with  blanks  > 

begin 

wordCi 1  :«  '  '; 
i  :*  i  +  1 
end; 

writeln (dictionary,  word);  <  Put  word  in  dictionary  > 


writeln (’ Input  alias  (replacement )  -for  input  word’); 

break (output) ; 

i  :=  l; 

read (ch) ; 

while  (ord(ch)  <>  10)  do  <  Stop  on  <CR>  > 
begin 

word! i 1  :=  ch; 
read (ch) ; 
i  :=  i  +  1 
end; 

while  (i  <  21)  do  {  Pack  with  blanks  > 

begin 

wordCil  ’  ’; 
i  ;=  i  +  1 
end; 

writeln (dictionary,  word);  <  Put  in  dictionary  > 

writeln (’Done?  (Y  or  N) ’ ) ; 

break (output) ; 

readln (ch) ; 

it  (ch  =  ’N’)  €  Spring-loaded  to  quit  > 

then  circle  :=  true 
else  circle  :  =  -false 


Appendix  J 
STD. DIC  LISTING 


< 

< 

> 

> 


EQUAL 

SC 

EQUALS 

LESSTHAN 

< 

LT 

< 

3REATERTHAN 

> 

0T 

> 

<> 

<> 

<> 

NOTEQUAL 

<> 

NE 

<> 

WHERE 

WHERE 

IS 

OR 

OR 

AND 

AND 

FOR 

FOR 

WHEN 

WHEN 

EQ 

PRINT 

PRINT 

GREATERTHANOREQUALTO 

>* 

>* 

>* 

GTEQ 

>- 

LESSTHANOREQUALTO 
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